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

Re: Notes on Requirements for Latin Text Layout and Pagination

From: Carlos Araya <carlos.araya@gmail.com>
Date: Fri, 10 Oct 2014 13:20:47 -0700
Message-ID: <CANL4y-qm5gD5Lu3-ZPcXgkEFGXoVO5uzA=FkQWnsgmYqyyYFYA@mail.gmail.com>
To: "public-digipub@w3.org" <public-digipub@w3.org>
Audrain,

There are tools that used the paged media and generate content for paged
media specs from W3C. These tools generate very good PDF output for print.
None of them, as far as I know, are open source. The css for paged media is
different than the css used for web content.

On the other end of the spectrum, there are tools that will scrape web
pages and print them. They will not work with paged media and their
generated content (at least they didn't work for me when I tried it)

Other members of the list may have had different experiences.

Carlos

On Fri, Oct 10, 2014 at 4:51 AM, AUDRAIN LUC <LAUDRAIN@hachette-livre.fr>
wrote:

> 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> a écrit :
>
> 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 Friday, 10 October 2014 20:21:15 UTC

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