Potential issue with landscape feature and AHFormatter

[frankarensmeier]

Earlier in October this year, the "landscape" feature was added to DocbookNG, which is highly appreciated. However, I’ve observed that it has the side effect of making rendering smaller documents take considerably longer with AHFormatter. For example, I have a simple test case where the resulting PDF document has 3 pages. Using docbook-paged.css from the 2.2.1 release, the document is generated in under 0.2 seconds, whereas the current release takes over 1 minute.

I realise that vendor-ahf-landscape.scss and vendor-ahf-portrait.scss add almost 1MB to the resulting CSS file. I’m curious to understand more about the background of this change. Perhaps there’s a way to simplify the CSS for AHF or explore other optimisations?

[ndw]

For documents that don't use landscape (or maybe that only use one orientation) it might be possible to avoid loading that CSS. I suppose it might be possible also to only load the particular combinations that are used by the document, but that seems potentially much more difficult. I'll have to see if I can reproduce the problem and confirm that those CSS changes are the problem. That might be a bug worth reporting to AntennaHouse as well.

If someone with more CSS skill than I can propose a simpler solution, I'd be delighted. When I investigated the problem, I concluded that the only way to make it work was to generate the full combinatorial matrix of possibilities. One more reason to consider biting the bullet and implementing XSL FO stylesheets, I guess.

I wonder if @tgraham-antenna might have any insights.

[tgraham-antenna]

html.article-style.#{$pagesize} body matches on a body descendant of html..., and so on for the rest of the selectors. It will probably be more efficient to use html.article-style.#{$pagesize} > body, and so on, to indicate a direct child relationship where possible.

You might instead do html.article-style.#{$pagesize} > * to save having to match on the name.

You might also try things like html.article-style.#{$pagesize} > *:not(.portrait), where possible, to save more matching on names.

It's not clear to me why html.article-style.#{$pagesize} body is needed if body is not going to change the page layout.

[frankarensmeier]

I have given this a lot of thought over the last couple of weeks. I believe that CSS can be made much easier by reorganizing it slightly and by separating "article" and "book" styles. The real culprit is that named page templates are not hierarchical—at least, not according to the CSS specs. (A non-named page template always takes precedence. A named page template can only override the default page template.) Let me try to outline my proposal:

1. page-setup.scss - Here, you would define the default page styling for articles (you could actually skip the class name article-style).

2. page-setup-bookstyle.scss - This file would contain the default page templates for book-style output. This also requires a minor change in head.xsl. Only if $page-style is set to book would that CSS file be used in the HTML file.

3. Draft Mode - Instead of using named page templates, you could use variables. The default page templates for articles and books would already have placeholder styling for the background. Instead of hardcoding the draft image, you would simply "turn on" the background image with a CSS rule like so:

.draft.left, .draft {
    --draft-background-image: url('draft-left.svg');
    --draft-background-position: 0.5cm 0.5cm;
}

4. Page Orientation (Landscape Feature) - This is tricky because it’s the only use case where you really need named templates. I was able to accomplish page rotation in a few different ways, but the outcomes were not very clean. So, I believe the only feasible way of achieving rotated pages is by using a named template. The drawback, however, is that you can only rotate normal body pages. Rotating anything else (e.g., the first page, back cover, etc.) would require additional work.

I understand that these kinds of changes can be a bit delicate. However, I believe that separating styling and simplifying page templates would significantly improve customizability. As it stands, the styles are difficult to understand and challenging to customize.

I have a working branch locally that I am happy to share. I would need some help ironing out the details and testing PDF output with different formatters (I have only tested with AH so far).