RE: [xep-support] Tab Stops

At 2007-12-17 13:49 -0500, Owens, Stephen P wrote:
>Thank you for your response. I don't have any particular layout
>requirement; I am trying to support a group of some 200-1000 authors who
>will be developing documentation all across the board. They currently
>use MS Word to do this, and it is uncertain what any particular author
>may want to do with Tabs, but it is a safe bet that collectively they
>would use tab stops in every conceivable way that they can currently be
>used from within MS Word.

Fine ... but Word is an interactive desktop publishing application
and XSL-FO is not. The publishing model for XSL-FO involves
describing a geometry of areas by locating their boundaries (not
their dimensions) and filling the resulting areas until the areas are
full, thus triggering new areas.

Consider that the width of the body region is not explicitly
specified in XSL-FO, rather, the margins between the page boundaries
and the body region are specified. Consider that the width of the
columns is not specified, rather, the number of columns and the gaps
between them are specified.

The flow model of XSL-FO requires one to pour content into
constrained areas ... the active formatting position is maintained
only for the purposes of stacking inline-level constructs that have a
particular width.

When I've had to mimic a single tab stop, I've used an inline
container of the width from the start of the line to the tab stop,
filled the container with the content I know to be less than the
width, then I've stacked the next information after the container,
which gives the appearance of a tab stop.

Consider the separation of content from format: your users are using
Word to create XML ... the tab characters would only have meaning if
you simultaneously captured the precise font metrics of all of the
characters they are entering. If one user uses larger text for data
entry, stopping a tab at the next .5in boundary doesn't make sense if
the font used for publishing is different than the font used for data entry.

>The long and the short of it, is that if it cannot be supported the way
>Word does, then we will probably have to introduce a change that
>mandates using alternative constructs such as tables for columnar
>layout, and maybe fixed spacing when using Tabs inline.

If the use of tabs is well defined, then why not allow your users to
use tabs and then have your XSLT interpret the tabs into columnar
layout constructs more easily formatted by XSL-FO? That way you
aren't sending data-entry-sensitive tab characters to a formatting
process that treats all white-space the same.

>The users will
>not like this, and will not be likely to appreciate an explanation that
>says 'the FO specification does not support it.'

Well, it doesn't support tab stops, but there are many ways to lay
out information. FO wasn't designed to replace an interactive
desktop publishing environment: the content is stacked on the line
until the line fills thus triggering another line. That is why the
use of the inline-container above supports a single tab stop when the
content is known to fit inside the inline-container.

>However, before recommending such a change in business policy, I would
>first like to confirm that there is definitely no technical solution to
>this issue.

Again, though, I wonder what is the "issue" ... positioning content
on a page, or interpreting a tab character and tab stops for a given
string of text characters with XML white-space using a set of precise
font metrics matching those used at data entry time?

If you aren't capturing font metrics at the time you are editing your
XML, what is the meaning of "move the formatting position to the next
point that is a multiple of .5in from the start of the line
area"? That might leave .4in on the screen in Word but on .05in in
the formatted output because XSL-FO is using different font metrics
than Word is using.

But, as I say above, if you see meaning in the tab character, then
your XSLT can interpret that meaning into the corresponding layout
construct. You get the best of both worlds: your users use tabs and
you can interpret the tabs with whatever semantics you want, not any
arbitrary semantics chosen by the FO committee.

>Anyone who reads this and sits on the XSL-FO committee, please take
>notice: Tab stops are a much sought after feature. Perhaps there is a
>fundamental reason (beyond 'it isn't part of the standard') that this
>capability cannot be supported, if so it would be nice to know what that
>reason is. Any help or insight will be appreciated.

I hope that someone from the XSL-FO committee does respond, but
honestly I can't see this as a "feature" that could be supported by
the existing geometry constraints of the formatting model.

And I would suggest you reflect on the use of Word for data entry for
XML: are you mimicking the Word publishing environment, or are your
users merely using Word as the data entry vehicle for getting content
into your XML structures?

If the former, then FO doesn't have all the features of an
interactive desktop publishing application. If the latter, then
revisit what DTP features your users are allowed to touch and which
should be either out of bounds or be interpretive signals you can act
on to get the effect intended by their use.

I'm trying to manage expectations ... I don't see the kinds of
requests that the committee receives from the public, but knowing the
foundational concepts of the formatting model may help understand
what is and is not available.

And, of course, it doesn't hurt to ask! The address I tell my
students to send XSL feature requests to is mailto:xsl-editors@w3.org
... then you know they will be formally reviewed and not left to a
mail list participant to file on your behalf. That address is there
for users to inform the committee of real-world formatting
requirements not met by the current specification.

But for the best response, be sure to express your need in terms of a
formatting requirement rather than a mechanical function.

I sincerely hope this is considered helpful and not critical.

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

--
Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/f/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/f/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html