Fixed layouts can be display modifiable

[mattgarrish]

In the visual adjustments section, the check for display modifiability is before the check whether a publication is fixed layout. This means that if someone claims their fixed layout is display modifiable, that overrides what would otherwise be said for it being a fixed layout.

Is that what's intended here? The appearance of fixed layout publications typically can't be modified, even if the markup theoretically allows them to be. I'm assuming that's why we test for fixed layouts and output the statement that the display cannot be modified in those cases.

Should these checks be reversed so that fixed layouts always result in the appearance not being modifiable?

[mattgarrish]

In case the above isn't clear, this is what we have in the epub techniques:

IF all_textual_content_can_be_modified: THEN display "Appearance can be modified". ELSE IF is_fixed_layout: THEN display "Appearance cannot be modified". ELSE display "No information is available".

I'm wondering if this should be:

IF is_fixed_layout: THEN display "Appearance cannot be modified". ELSE IF all_textual_content_can_be_modified: THEN display "Appearance can be modified". ELSE display "No information is available".

The "else if" would never be reached for fixed layouts this way.

[GeorgeKerscher]

To me when the content designer makes the decision to make it fixed layout, the intention is that it would not be modifiable. While it is theoritically possible for a reading system to make modifications, I think we should state that the appearance is not modifiable.

[gregoriopellegrino]

This is intended for two reasons:

• from our discussions we had decided that what is declared in the accessibility metadata always takes priority over any heuristic calculations
• there are Fixed Layouts in which content creators allow font family, font size, and color theme to be changed, using JavaScript (e.g. EPUB Fixed Layout created for readers with dyslexia)

[mattgarrish]

from our discussions we had decided that what is declared in the accessibility metadata always takes priority over any heuristic calculations

It's not really a heuristic test as much as which metadata takes priority. We're not inferring an accessibility feature that hasn't been stated. Normally, I'd agree that author metadata should win, but in this case what definition of display transformability is being applied? That's what worries me.

there are Fixed Layouts in which content creators allow font family, font size, and color theme to be changed, using JavaScript

The problem is that these are only some of the display transformability properties listed in the property definition. It's probably a bad idea to set up different expectations of what can be transformed based on the layout being fixed or reflowable. Or are you saying that there are fixed layouts that allow control over all the same aspects?

Maybe there should be another category of fixed layout and display transformable that gives a different cautionary string ("Appearance may be modifiable"?). But I'd still be worried about authors using displayTransformability for fixed layouts if it means a smaller set of properties are controllable. We've already struggled with this for reflowable publications.

[gregoriopellegrino]

there are Fixed Layouts in which content creators allow font family, font size, and color theme to be changed, using JavaScript

The problem is that these are only some of the display transformability properties listed in the property definition. It's probably a bad idea to set up different expectations of what can be transformed based on the layout being fixed or reflowable. Or are you saying that there are fixed layouts that allow control over all the same aspects?

One example I know is the FXL EPUBs from MobyDys. I don't have the full list of features that are implemented, but potentially with JavaScript you can implement all the ones indicated by displayTransformability.

Maybe there should be another category of fixed layout and display transformable that gives a different cautionary string ("Appearance may be modifiable"?). But I'd still be worried about authors using displayTransformability for fixed layouts if it means a smaller set of properties are controllable. We've already struggled with this for reflowable publications.

Yes, I agree that we can use a different string in case of EPUB Fixed Layout with displayTransformability. If then the displayTransformability metadata is "abused" it is the responsibility of the content creators. In our experience we see many publications declare that they contain longDescription or MathML, without having any :)

[mattgarrish]

If then the displayTransformability metadata is "abused" it is the responsibility of the content creators.

Right, there's nothing we can do about that.

But we should distinguish content that the user can modify any way their reading system allows versus properties that the author is making available. In the case of fixed layouts, the user won't know if those properties are fully useful until they open the book.

With a different string, we should be able to come up with a way of differentiating these cases.

[HadrienGardeur]

there are Fixed Layouts in which content creators allow font family, font size, and color theme to be changed, using JavaScript (e.g. EPUB Fixed Layout created for readers with dyslexia)

I think that documenting displayTransformability for such publications is a mistake. While they might allow some visual adjustments, they won't necessarily cover the range of adjustments that I need as a reader.

[gautierchomel]

There are also ebooks FXL with inside links leading to the equivalent Reflowable resource. There are few, but they exist.

In any case, it's the publisher's responsibility; if the display transformability is informed, we should display it. It's not up to us to determine if this is true or false.

[clapierre]

I think if there is both "fixed layout" and "display transformability" together (assuming this isn't a mistake, but even if it is by mistake) we should have as the first IF (FXL & Transformability) display "Appearance may be modified", then do the separate ELSE IF transformability, and ELSE IF FXL, and finally the ELSE display "No information is available"

[gautierchomel]

Probably the problem is we should find a word that describes the fixed layout experience benefit for readers like : Faithful to the Original Design or Consistent and Predictable Experience.