W3C home > Mailing lists > Public > public-ppl@w3.org > February 2013

Re: Customer requirement, a critque

From: Tony Graham <tgraham@mentea.net>
Date: Sun, 24 Feb 2013 14:51:02 -0000 (GMT)
Message-ID: <61092.94.197.127.177.1361717462.squirrel@mail3.webfaction.com>
To: "Print and Page Layout Community Group" <public-ppl@w3.org>
On Sun, February 24, 2013 1:43 pm, Dave Pawson wrote:
> On 24 February 2013 13:13, Patrick Gundlach <gundlach@speedata.de> wrote:
...
>> Its not related to #1. There are arbitrary rules a customer can state
>> about how to reach that goal. Implementing all these rules is impossible
>> in a formatting engine, because these rules are highly dependent on the
>> situation.
>
> Eventually they will come down to an fo specification for pagination
> in a formatter?
> That is my target, it seems we differ somewhere Patrick?

Patrick kick-started the current discussions by revealing (from our
perspective, anyway) his non-FO solution, which he also presented about at
XML Prague, so it's more likely than not that you do differ.

>>> 4. Is that a verb? (To catalog?)
>>
>> No sorry. I meant "product catalog"
>>
>>>   IMHO the formatter needs a get out clause? It is known that some
>>> languages (German?) are incredibly
>>>  verbose compared to others. Is there any language for expressing
>>> max-white-space? I.e. if the ws
>>>  gets more than x% then just do your best, or something along these
>>> lines? How else to provide
>>> the get out for the formatter, or would you want horrible big white
>>> space?
>>
>> If a language A takes up 5 lines and another language B takes up 20
>> lines, then yes, in this case I want the whitespace to be 15 lines.
>
> So what would you want to happen when the shorter language results in
> 'too much' white space?
> In your example, 75% white space? That seems impractical to me.
>
>
>>
>> The goal is to make all color (images) in all product catalogs (n
>> languages) exactly in the same space. But it should not contain
>> unnecessary whitespace. So the "longest text" products determine the
>> positioning of the color images. See my two pdf files I've uploaded to
>> the wiki.

Patrick's XML Prague slides showed it better, I think.

>>> An alternative could be
>>> expressed as 'fit these items in the same number of pages' in all
>>> languages?
>>
>> No. See the constraint above (color images on the same space)
>
> OK, I'll disagree with this requirement, on the grounds that the
> result would be bad typography.

Sometimes cost trumps typography.  Probably especially so when the output
has as limited a lifespan as a catalogue.

>>> 5. I don't understand this. What images? Provided by whom? Would an
>>> easier one be to simply
>>> say, where a container has n-columns, to require column-balancing?,
>>> i.e. leave ws at the end of
>>> the two columns, in equal quantity?
>>
>> I've uploaded another pdf for that.
>
> Where please?  URL?

Linked to from the wiki page at
http://www.w3.org/community/ppl/wiki/CustomerRequirements

In Patrick's case, as I understand it, the English and German versions are
separate publications, not two columns on the same page.

>>> 6. Is this a corner case Tony? I don't know. I can see the use where
>>> 'which page this block goes on'
>>> does not matter. IMHO your example is too specific?

It is unusual, yes, and not at all easy either declaratively or through an
API, or so it seems to me.  However, customers don't always come with
problems that have nice, easy solutions, nor do they couch things in
XSL-FO terms.

>> It is a very specific customer requirement (which this page is about). I
>> am not sure how to generalize that.
>
> Do you think such a specific use case is applicable for a general
> specification such as XSL-FO?

If we made FOs (or API functions) for those specific actions, yes, it
would be too specific to be generally useful.  So for now, it's probably
best to treat it as indicative of the sort of thing that real-world
customers can want: you and I may not find pictures of brake discs to be
particularly interesting, but some people obviously do, and Patrick's
client has presumably wanted it organised in a way that would be most
useful for selling to disc-brake fans.  And back in the good old, good old
days, that would have been done by pasting down lots of little photos of
brake discs and little snippets of text, taking a photo of it all, and
sending that off to the commercial printer.  We probably can't standardise
everything you used to regularly do with a scalpel and a pot of glue, but
that doesn't mean that it's already time to limit our options.

Regards,


Tony.
Received on Sunday, 24 February 2013 14:51:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 24 February 2013 14:51:31 GMT