RE: [xsl] FO to format unstructured XML containing "tabs"

["Kyle Partridge" <kpartridge@xxxxxxxxxxxx>]

Hi Ken,

After looking more into the formatting of the inline-container stuff you
mentioned, I think I have found a good reason to use either tables, or
leaders.  I'm not sure yet what those higher up will decide, but my
reasoning is, if you had three items, and you used inline containers to
line those up - if the third item *only* wrapped around, that works out
OK...but what if the first item *and* the third item wrapped around?
Maybe I did something wrong, but I got something like this:

item1ite item2     item3item3item3
m1item1  item3item3item3item3item3

which I personally think is more confusing than either the table option
or the leader option.  My XSLT will wind up being complicated anyway,
but even more-so I guess because I want to differentiate between
"systematic" use of tabs (calling for a table treatment) and
"incidental" use of tabs (calling for leader treatment).  I'm not sure
what "rule" I can use to ascertain which is appropriate, but if I can
come up with something that looks decent 75% of the time, I guess I'm
happy...for now.

Does this seem reasonable or ridiculous to you?  

I so appreciate your insights on this.

KP


-----Original Message-----
From: G. Ken Holman [mailto:gkholman@xxxxxxxxxxxxxxxxxxxx] 
Sent: Tuesday, December 16, 2003 2:30 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] FO to format unstructured XML containing "tabs"

At 2003-12-16 13:39 -0500, Kyle Partridge wrote:
>ASCII art sometimes doesn't reflect a lot of nuance ... are you just
>showing that item5 begins to the right of item2?
>
>         Yes, exactly.

Fine ... that can be fixed by an inline container.

>Where do you want item3 if item2 is longer than the tab location?
>
>         Hmmm... That's a good question.
>
>         What I want is for these "tabs" to behave like "tabs" behave
in
>a word-processing program...so, if item4 runs over it's allotted space,
>then, "pressing" tab should just bring you to the next "tab stop".

That I cannot do for you in XSL-FO ... this is because at transformation

time one has no idea of formatted lengths.

>If <p tabs="0.2 1.2 2.2">

Are those inches?  You still haven't described what this is for a 
specification.

>then that should indicate "tab stops" within
>the paragraph block? Sort of like (* indicating a "tab stop"):
>
>-*-------*-------*------------------------
>  item    item2   item3
>  item4   item5 blah blah and if i say <tab> now, nothing happens,
there
>are no more tabs
>
>If item2 is longer than the tab location:
>-*-------*-------*------------------------
>  item    item2 goes on too long...item3 (because the tab before 3 is
now
>meaningless)

Being the last tab stop, my ideas would work, but if item1 went past the

desired stop of item2 I could not provide for you item2 starting at
where 
item3 would have started.  Given that item1 overflows its tab, I could 
start item3 as far away from the start of item2, with item2 starting 
shortly after (or immediately after) item1 ... would that be acceptable?
I 
acknowledge that on a long list of lines on a page this would stick out 
like a sore thumb.

If not, then we know right away (I think) that XSL-FO cannot give you
what 
you are looking for ... yet another reason to do this.

Truncating the data would guarantee that all of the columns would line
up, 
but then you'd be missing data.

Wrapping the data in a tap stop would guarantee that all of the columns 
would line up and you wouldn't be missing any data, but you would get
some 
doubled-up lines.  You could distinguish the starts of lines by having
the 
wrapped tab stops be indented.

Would either of the above be acceptable?

BTW, for those on the list who attended my presentation last week at 
XML'2003 on formatting specifications, doing this is what I called
creating 
the prototype in XSL-FO, which is done after someone might produce a
mockup 
in some other technology for visualization.

........................ Ken

--
North America (Washington, DC): 3-day XSLT/2-day XSL-FO 2004-02-09
Instructor-led on-site corporate, government & user group training
for XSLT and XSL-FO world-wide:  please contact us for the details

G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6                       Definitive XSLT and XPath
ISBN 0-13-140374-5                               Definitive XSL-FO
ISBN 1-894049-08-X   Practical Transformation Using XSLT and XPath
ISBN 1-894049-11-X               Practical Formatting Using XSL-FO
Member of the XML Guild of Practitioners:     http://XMLGuild.info
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/s/bc


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list