Re: Notes on Requirements for Latin Text Layout and Pagination

Hi Dave and all.

Still want to thank you for the trememdous job of latinreq specs.

When reading these comments, I'm puzzled. Are we not reinventing the wheel? Isn't there any open source HTML composition tool that can be driven by CSS?

Luc


Le 7 oct. 2014 à 22:49, "Dave Cramer" <dauwhe@gmail.com<mailto:dauwhe@gmail.com>> a écrit :

On Mon, Oct 6, 2014 at 12:14 PM, Jacob <jacob@subsumo.com<mailto:jacob@subsumo.com>> wrote:
Hello all,

I’ve recently joined the group with hopes of creating a flawless system for text layouts and, eventually, being able to create and print well laid-out PDFs directly from a page. The working draft is an excellent document. Here are some notes on the issues at-hand which should be of some use:

 *   5.1 Widows<http://www.w3.org/TR/dpub-latinreq/#widows>
    *   Pagination of 'Digital Content '
       *   If so, this does not take into account differing screen heights
       *    properties should be considered (widow-preference) to lay out the text:
          *    “running short”
             *   run-short (default)
             *   space-words (small space adjustments between words to satisfy spread)

Running short or running long depended a lot on the design. We'd get instructions on which was allowed (rarely both). This was the preferred method because it didn't affect the spacing of text.

Being able to specify limits on how much word- or letter-spacing is allowed would be lovely. Old drafts of CSS Text [1]  had spacing limits, where you could indicate minimum, optimum, and maximum values for word- and letter-spacing, much as you can with page layout programs today. But there wasn't much implementation interest.


 *   5.6 Space Breaks and Ornaments<http://www.w3.org/TR/dpub-latinreq/#space-breaks-and-ornaments>
    *   Can be mimicked with CSS
       *   Could a use the <br> tag? Ideally, p+br or br+p
          *   p+br :: page - ( top || bottom || inside)
       *   Perhaps page p:: last-of-type:after { content: ‘ * * * ’ }



 *   7.1 Drop caps<http://www.w3.org/TR/dpub-latinreq/#drop-caps>
    *   IMO, punctuation falls into the category of an ornamental and, as such, would fall outside the spacing of letter.
       *   If CSS were to be used, :first-letter:before { content: “*”} and :after { “” } would suffice.

I'd expect that future work on wrapping text around initial letters would be based on CSS Shapes.

p::first-letter {
  initial-letter: 3;
  shape-outside: {some new value for text};
}


 *   11.1 Alignment<http://www.w3.org/TR/dpub-latinreq/#alignment>
    *    Flush left centre alignment naming
       *   text-align: migrate ( -left || -right )

When I think about migration, it brings up visions of rather longer journeys. I would think the most likely path forward would be to resurrect the 'string' value for text align [2] and perhaps add a new keyword.

Once again we find a useful property which didn't elicit much interest from implementers.


 *   17.3 Aligning equations<http://www.w3.org/TR/dpub-latinreq/#aligning-equations>
    *   text-align: migrate ( -left || -right )

This may be even trickier, as the things to be align may not even be in contiguous elements. I'm curious how MathML and TeX might handle this issue.


 *   19.2 Em-dashes and en-dashes<http://www.w3.org/TR/dpub-latinreq/#em-dashes-and-en-dashes>
    *   Style guides in the AP dictate the usage of spaces.

Note that there are many different style guides, some of which are public like AP, others of which exist only within organizations. Consensus does not exist on some of these issues—where I work the people on the 15th floor handle em-dashes differently than on the 16th floor.

       *   Solution: Use font-face to provide a single-glyph subset, (http://www.w3.org/TR/css3-fonts/#font-style-matching)
          *   Publishers have the in-house capabilities to be able to provide font-faces with different glyphs, rather than using style replacement mechanisms.

So the idea would to use Unicode-range on fonts to point to an alternate font for certain characters that would include some built-in space in the glyphs?

I think this runs into several issues:

1. You may be overestimating the technical skills of publishers
2. Some of these replacements depend on context. An ellipse which followed by a close double quote results in different output than an ellipsis which is followed by a space.
3. Any solution that involves altering fonts runs up against lots of problems, not the least of which is that it might be illegal to alter the font.


          *   However, this eliminates the extra ‘spaces’ when copying the text.
          *   As a rule of thumb, we know CSS should be used for stylistic purposes. Is the solution simply to always add the small spaces around the dash?

Given that authors can just put anything in HTML, and we could postprocess to solve some output issues, I don't think this is terribly important. But we have found prince-text-replace to be extremely useful in our workflow.


 *   22.2 Chapter optimization<http://www.w3.org/TR/dpub-latinreq/#chapter-optimization>
    *   Some excellent baseline and page layout mechanisms can be derived from Grid Systems in Graphic Design by Josef Muller-Brockmann… are these worth exploring?

What I'd love to see is some description of what requirements these mechanisms satisfy. Grids can be used to align things. What things are supposed to be aligned?

Thanks for the comments—much appreciated!

Dave

[1] http://www.w3.org/TR/2012/WD-css3-text-20121113/#spacing

[2] http://www.w3.org/TR/2012/WD-css3-text-20121113/#character-alignment