[xep-support] Tab Stops

[G. Ken Holman]

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