W3C home > Mailing lists > Public > public-digipub@w3.org > October 2014

Re: Notes on Requirements for Latin Text Layout and Pagination

From: Dave Cramer <dauwhe@gmail.com>
Date: Tue, 7 Oct 2014 16:48:56 -0400
Message-ID: <CADxXqOyLAbpnyZuVrqOZMm2CqX-MCfeDcfs-mSpZzmcdELuv9g@mail.gmail.com>
To: Jacob <jacob@subsumo.com>
Cc: public-digipub@w3.org
On Mon, Oct 6, 2014 at 12:14 PM, Jacob <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
Received on Tuesday, 7 October 2014 20:49:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:20 UTC