Repository navigation
Inference rule for visual adjustments (displayTransformability) #16
Description
Based on our work for parsing HTML/CSS (#180) we'll add a new inference rule for visual adjustments.
For this issue, we'll use a fairly naive approach where the metadata is only inferred if problematic CSS rules (TBD) are completely absent from both external stylesheets and inline styles.
Nonvisual reading ("accessModeSufficient": "textual") is also a pre-requisite to infer this metadata.
For further info, we can check the Daisy KB and the page dedicated to this property:
The displayTransformability value is used to indicate that a publication does not restrict the ability of users to modify the display of textual content (e.g., to change the font family, font size, line height and word spacing).
In order to set this value, all text content must be encoded as text (i.e., there must not be any images of text). In addition, absolute length units must not be used in the styling (e.g., pixels and points).
It is not required that a publication provide the means of transforming the text. It is expected that users who require this feature will have a reading system that with display transform options.
Since this additional inference requires parsing all HTML/CSS resources, it'll be added behind a new optional flag for both rwp manifest and rwp serve.
Activity
HadrienGardeur commentedon Dec 22, 2025
After further discussions, we want to lower the bar for this inference:
Compared to the DAISY KB definition, this won't require parsing CSS or checking for various styles since we believe that most RS are capable of dealing with these limitations.
gautierchomel commentedon Jan 16, 2026
I believe we should be more cautious with this approach, focusing on the ebook metadata rather than the reading system's capabilities.
Instead of automatically inferring the display transformability metadata, I recommend that we provide options to extract potentially problematic CSS values. Users would then have the choice to infer this metadata using a dedicated flag after reviewing the CSS extracts.
This would grant users greater control and transparency over the inference process, rather than allowing the tool to make assumptions that may not always align with their specific use cases.
JayPanoz commentedon Jan 16, 2026
Isn't this a bottomless can of worms tho, depending on what level of heuristics you want to achieve?
From Readium CSS' painful experience, we know combinations of styles either directly declared for an element or inherited through the cascade, media queries for themes, etc. can effectively have the same effect as a problematic CSS value in itself so it could be quite challenging in some cases.
gautierchomel commentedon Jan 16, 2026
We should disconnect both discussions:
displayTransformability. Reading systems confident in the fact that they can deal with CSS limitations can display this information for all reflowable and textual sufficient publications.displayTransformability. We don't need to cover all usecases, just to point potential problems for the user to check. I would start with a list of units :px,pt,cm,mm,in; positioning :position: absolute,position: fixedand overrides :!important.HadrienGardeur commentedon Jul 27, 2026
We're dropping this one for now, we'll revisit what it takes later.