Re: [css3-text] spacing limits are not interoperable

Hi Alan,

> >As I mentioned previously at the San Diego F2F [3], I don't think
> >it makes sense to define fine-grained parameters like this without
> >also specifying normatively the justification algorithm with which
> >they are used.
> 
> I don't think it makes sense to have a single justification
> algorithm. We don't specify a line breaking algorithm as
> specifically as you appear to be requiring for a justification
> algorithm. People expect to see slightly different line breaks in
> different browsers, and so they should also expect to see slightly
> different justification results in different browsers

I am by no means arguing for a single, grand unified justification
algorithm.  But I don't think fine-grained spacing controls make sense
as settings that apply to *all* algorithms, in particular to ones that
are relatively crude (e.g. line local algorithms).

> >Authors don't use these parameters as real absolute limits, they
> >tweak them visually based on the results in a given implementation
> >for a given text layout.
> 
> I don't think that's the case, or at least it should not be for
> reflowable text. In high-volume print production environments (which
> are somewhat analogous to reflowable web text in that there is no
> attempt to make line-by-line tweaks) the min/desired/max spacing
> controls are used in a style sheet to create a similarity in color
> over multiple articles or publications. Tweaks are made to the style
> sheet, not individual results.

Right, I understand this workflow and it points out the key
interoperability problem, that the justification algorithm used both
in the design and production phase are the same.  An author judges the
"color" based on a finite set of samples using the same justification
algorithm that will be used in the actual print run.

This is where browsers differ from print environments or applications
like MS Word and InDesign, the output will likely be viewed in a
mixture of user agents, using a jumble of justification algorithms.

My guess is that XSL-FO formatters are the same way, these settings
are only consistent when used with a single implementation or at least
across implementations that share a common algorithm and/or
implementation.

> >In an implementation which implements a "better" justification
> >algorithm (e.g. a paragraph global algorithm rather than a line local
> >one) this might lead to suboptimal results which would discourage the
> >use of improved algorithms.
> 
> Is this concern stemming from this set of steps?
> 
> 1. Set spacing controls
> 2. Look at the results in a simple justification algorithm
> 3. Tweak the content based on specific line endings to
>    look good in a specific browser
> 4. Now the tweaks applied in step 3 make the content in
>    a different browser look worse
> 
> I agree that step 3 is bad, but it's a bad thing to do even without
> spacing controls. I don't see how shuffling between steps 1 and 2
> until it looks good in one browser would make a different browser
> look worse (unless you're changing min/max settings to absurd values
> in a browser whose justification algorithm ignores them).
> 
> What is your scenario where improved algorithms are discouraged?

Yes, this is precisely my concern, that authors will perform step (3)
in a browser with a justification algorithm optimized primarily for
speed rather than quality such that when those same parameters are
used within a higher quality implementation, the results will be
crippled.

To put it another way, hopefully a quality implementation with good
hyphenation obviates the need to use spacing controls.  Spacing
controls could easily end up as simply be a way for authors to try and
make up for inadequacies in lower quality implementations, to the
detriment of the display in higher quality implementations.

I think there are good reasons to (1) wait on specifying spacing
controls and and (2) restrict these controls to justification
algorithms with some minimum level of sophistication to minimize their
use as a way of making up for inadequate implementation quality.

Regards,

John Daggett

Received on Wednesday, 5 December 2012 00:58:54 UTC