Re: [csswg-drafts] [css-page-3] Add orientation descriptor (#4491)

Sorry for the long delay, I got caught up in many other issues.

**TL;DR:**

Introduce a new `orientation` descriptor. It has three values: `default`, `rotate-right`, and `rotate-left`. In the case of PDF output, it is expected to map directly to the `Rotate` PDF command.

Purpose: apply rotation to PDF output in cases where the most important content has a different orientation than the one from layout.

Semantics: the entire content of the page is rotated when `orientation` is applied, including headers and footers and margins. Layout of the page contents, including aspects such as mixed orientation or writing mode, is unaffected.

In cases where page content has mixed orientation, such as headers and footers differing from page contents rotation, this will result in the header being drawn "sideways" in a PDF display, but as mentioned in the use-case analysis below, this is desirable.

---

Detailed comments below.

Some printing folks in Chrome also looked through various data sets and found examples similar to the ones mentioned in previous comments. They also didn't find examples of the entire page rotating with headers, without already drawing the content in a layout PDF page. Instead, it can be common to have content whose internal sizing fits better to landscape than portrait, so as to have *two* rotations in the same page. The reasons include:
1. tabular data that is better presented with those dimensions
2. large images that are wider than they are tall
3. bitmaps generated by an external formatting system, such as an advanced word processor, or external offline or "legacy" system that generates content

In addition, the headers and footers often have orientations that conflict with the orientation of the content, because the printed page is meant to be presented in a book or pamphlet with a single orientation for each page. The reader of the book is expected to turn it when reading the rotated sub-content.

The original motivation for filing this issue was use case 3. In particular, a word processor such as Google Docs has a different layout and formatting system than the web, and for these reasons performs its own layout and may even draw the results to Canvas instead of DOM elements. On top of this, such "web-based" word processors can often support page sizings that are more advanced or specialized than the user agent's. (*)

(*) Examples: Chromium and WebKit only have limited support for variable-size/shape pagination. OTOH, a word processor often wants to be able to print mixed page sizes and orientations. Regardless, however, it's easy to see that there are plenty of offline, legacy or otherwise non- "web-based" word processors or content generation systems that are unable to generate DOM output, but that nevertheless benefit from being integrated into web content for viewing or printing.


-- 
GitHub Notification of comment by chrishtr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4491#issuecomment-590609738 using your GitHub account

Received on Monday, 24 February 2020 23:58:32 UTC