Re: Customer requirement #1: Decrease font size

On 21 February 2013 14:34, Tony Graham <tgraham@mentea.net> wrote:

>> 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?

I'm (for now) ignoring inheritance and only considering copyfitting, i.e.
dear formatter please fit THIS block (not a page/ or anything larger)
into (e.g. remaining space on a page).


>
>> 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?

I had not considered it so widely Tony?
  IMHO a page isn't something I want to fit into anything?
  I think fitting relates to content, i.e. some block of text or graphic?

I was at block or block container level,
requesting it be fitted into this space, by adjusting, e.g. font?
  I *think* the formatter needs to know
    What can be adjusted to fit a block into a space
    What (if nothing else is given) the fallback values are.
  Hence I proposed providing local 'variables' for the block,
   either within the bock properties, or externally, I'm not bothered where,
   just trying to suggest ideas what needs to be specified?


>
>> 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
> requirements.

On the wiki - will do, this weekend.


>
>> 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.

Until we get something, a proposal, that is incompatible with an xsl
1.1 processor
I can't see any reason to consider it?
   Simple proposal then, anything we add is applicable only when some version
on the fo is > 1.1?


>
> 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.

So put  1.1 on the fo file?

  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.

Which is a rock and a hard place position?
I'd say that's a user choice, upgrade or don't?
But I'm not prepared to worry about it just yet.


>
> 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?

My view only.
   Put new features in a list.
   Vote each one in / out with a compatible upgrade (1.2 say)
   If not, put it into 2.0

HTH



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

Received on Thursday, 21 February 2013 15:13:12 UTC