Re: Customer requirement #1: Decrease font size

On Tue, February 19, 2013 2:19 pm, Dave Pawson wrote:
> On 19 February 2013 14:10, Tony Graham <> wrote:
>> * How well or badly does decreasing the font size fit with the
>>   previous WD's approach?
>> * Is adjusting things with .minimum and .maximum a useful approach
>>   for specifying copyfitting limits?
> Two thoughts.
> 1. I want to specify global options, e.g.
> font-size.min  .max And keep everything within these limits?
>  These would be fallback values

I was trying to get the conversation to walk before it ran so didn't talk
about scoping, but why would you not expect properties to be inheritable?

> 2. I may want to have the formatter adjust one specific area / block /
> block container within
> tighter (or slacker) limits.
>   Could we take both into account?

I'm sure we could.  Can you be more specific?  For example, is it
necessary or not to be able to specify copyfitting that applies only on
odd-numbered pages and not on even-numbered pages?

> Something like a layout specification file external to the xsl
> stylesheet, or specific to the formatter,
> then add something to fo:block font-size.max='24pt'  ?

You could try looking at Patrick's description and recasting that into
more XSLish terms and see how well or badly that could serve the stated

> As regards backwards compatibility, IMHO that is not an issue?

Backwards compatibility of what w.r.t. what?  Patrick's solution isn't
backwards compatible with anything, and knowledge of its existence
galvanised a subset of the people here to want to talk about more feedback
within XSL formatting.  There's a whole spectrum of ways that what we
produce could be incompatible with XSL-FO 1.1, and if we tried we could
probably find several ways to cheese off existing XSL-FO users by making
their existing stylesheets not work.

If copyfitting, et al., becomes the killer app for XSL-FO, then backwards
compatibility wouldn't matter, but we've already heard from Ken and we
already know that there's a class of users for whom the output takes as
many pages as it takes.  There's other expressed requirements such as #9,
"Ability to modify label field width in a single list when labels are
large.", that would be useful to the as-many-pages-as-it-takes users, but
I can't see them upgrading for that if it breaks the rest of their work.

Is there any consensus on the importance of backwards compatibility and
the threshold for when a feature is important enough to justify being
backwards incompatible?



Received on Thursday, 21 February 2013 14:34:43 UTC