grayscale reinterpreted as "foreground-scale"

3 posts / 0 new
Last post

I'd like to propose a feature for the next major revision of EPUB (3.1?). How can I make an EPUB feature proposal? Do I need to join the IDPF?

Here's the feature, in a nutshell: the ability to request that a grayscale image be reinterpreted as "foreground-scale," i.e. the ability to have a grayscale image match the current foreground/background color scheme for text.

I describe the feature at greater length in the following blog post:

http://dencklatronic.blogspot.com/2014/09/the-web-needs-bitonal-images.html

Although this feature could, and perhaps should, be implemented in HTML, CSS, or in an image format, this feature is more sorely needed in the EPUB context than in the general web context.

The reason it is more needed in EPUB is that only in the EPUB context are user-selected foreground/background color schemes so important.

Thanks for any help as to how I can advocate for this feature.

Concerning the SVG questions in the referenced article:

You can use for attributes/properties with a color as attribute/property value the value 'currentColor', this uses the color specified for the attribute/property color - if one specifies this in a stylesheet applicable both for the XHTML part and the SVG part, if applies for both.
Even more, if one does not place a specific element as background in SVG, the background is transparent in SVG, for embedded SVG documents or fragments, this means the same background as specified for the embedding document.
And of course, one can always apply the same stylesheet document to both, XHTML documents and SVG documents.
Typically you need a complete stylesheet, because for the SVG content you may want to
switch much more colors than only background and color.
As in XHTML you have the class attribute, the id attribute and you have all CSS selectors for
SVG as well, therefore for an alternate stylesheet you can switch all colors you want for the SVG as well.

Remaining problems are often related to implementation bugs, for example some viewers
do not allow to switch between alternate stylesheets at all or do not switch the style for referenced documents as well, if they have an alternative style with the same name.
Even worse the bug of some viewers ignoring the style information about the background-color, but not about the color or allowing the user to change the background-color without the option to do the same for the color as well - often this results in nonsense presentations. For example in readium one can observe such viewer behaviour creating accessibility issues.
Due to these implementation bugs or gaps of course, the practical use of alternate styles is nothing that really works in a convenient way for the audience and the feature to select the background-color in the viewer is practically broken, if the viewer still interprets parts of a stylesheet - such a mixture often results in inaccessible presentations. If a viewer just ignores the background-color information in the stylesheet of the author, this can result in an inaccessible presentation as well - this is a fatal bug of such viewers, but nothing an author has a practical tool for to care about - at least not for XHTML+CSS.
One method for the SVG content is to use consequently presentation attributes and a large background object to get some defined primary view - additionally one can generate alternative
stylesheets, for example with not displaying the background element to get the background from the embedding document etc.

Obviously for pixel images the situation is not so comfortable as for SVG content - one option could be to embed the pixel image into SVG and apply filters to them to style the color distribution. Because there is a filter property in SVG as well, you can select different filters with different stylesheets.
There is already a CSS draft for a module to use (SVG-)filters in general for styling, this may solve your problem completely, but this is not yet a recommended module and not applicable for EPUB. In EPUB filters are currently limited to SVG content.
In practice it is not a good idea to put the XHTML content into a foreignObject within an SVG document to be able to apply filters for XHTML+CSS as well for several reasons - usually the
presentation and functionality of foreignObject content suffers due to implementation bugs and gaps as well.

Haven't had a chance to read your proposal, but to your question about requesting features: the EPUB working group uses a google code issue tracker to manage requests and bug reports. You don't have to be a member of the IDPF to open a ticket.

The 3.1 revision is expected to begin later this year or early next -- you can track the status at http://idpf.org/ongoing. Until then, you're probably not likely to hear anything in response.

Secondary menu