[xep-support] Re: table column widths correct in FOP but not in XEP

[Kevin Brown]

Ø  This seems to be a fundamental usability flaw in the spec.

 

No, this is a problem in the way DITA XSLs are writing FO content. It really
has nothing to do with the specification.

 

Ø  Most authors are unlikely to even know that a default @width="100% value
is being written to the FO.

 

Correct. This *is* the problem. The DITA XSLs should likely be corrected so
that the behavior is as it should be. No width at all should be set.

 

Ø  So, in short, by honoring the specification, XEP is forcing tables to
span the page body, regardless of an author's column width specifications.

 

This is wrong. XEP is not forcing anything. XEP is only doing what you ask
it to do 
 with regards to what you have written in your XSL FO document you
are giving to it.  If you do not want page-wide tables, do not add
width=”100%”.  Please ask yourself this question 
 if we ignored
width=”100%”, how would anyone get a page-wide table? 

 

We are not forcing anything. Please keep in mind that DITA is a markup
standard and the XSLs are there for you to add/modify/change to how you
wish. If you remove whatever is putting width=”100%” on your tables, you
would have two columns in a table of the exact sizes you specified. XEP
doesn’t put that on, nor does DITA in general 
 the XSLs that are written
for and processing DITA content do. This is where the problem lies.

 

Ø  I understand that in this respect, XEP is staying true to the
specification, which is usually a very desirable thing. But I hope you can
understand why the result of this honoring is not desirable and might be
worth a revisit.

 

No this is not correct. The Spec is the law, and the behavior is known,
documented and consistent (except some formatters do not format it
correctly). The issue in reality is not with FO, but with how the FO is
being created. If the DITA XSLs are adding width=”100%” always, they should
be changed and the issue lies solely with DITA. Again, what would happen if
tomorrow you *want* a table that is 100% wide. How would you get it then?
You just asked us to ignore it, then would you want us to honor it?

 

I have already posted this also to the dita community, but again there is a
reason for standards. They are *standards*, if other products do not adopt
those standards correctly, RenderX does not change their product to match
what is wrong.

 

Kevin Brown

RenderX

 

From: xep-support-bounces at renderx.com
[mailto:xep-support-bounces at renderx.com] On Behalf Of LW White
Sent: Wednesday, June 15, 2011 2:21 PM
To: XEP Support
Subject: [xep-support] Re: table column widths correct in FOP but not in XEP

 

Eric, Ken, Kevin--

Okay, I have a better understanding of the issue now, I think. While the
spec could hardly have explained the default behavior in a more confusing
matter, my interpretation is that if the @width value is greater than the
sum of the column widths, use that and enlarge the columns accordingly. I
can only assume that the reverse is also true...if the sum of the column
widths is greater than the @width value, use that. In other words, let
tables run over into the margin.

This seems to be a fundamental usability flaw in the spec. In DITA, the
table width cannot explicitly be set by an author (i.e. there is no @width
attribute for table). Most authors are unlikely to even know that a default
@width="100% value is being written to the FO. Instead, an author will size
individual columns as desired, with the expectation that those widths
comprise the total table width and will be honored by the FO renderer.
(Apparently @pgwide=0 is supposed to force the OT to honor column widths but
it does not appear to be working.) So, in short, by honoring the
specification, XEP is forcing tables to span the page body, regardless of an
author's column width specifications.

I understand that in this respect, XEP is staying true to the specification,
which is usually a very desirable thing. But I hope you can understand why
the result of this honoring is not desirable and might be worth a revisit.
While FOP's failure to consistently conform to the spec is often
frustrating, in this case, it produces the desired and expected
result...whether by accident or design, who can say!

Best,
Leigh
!DSPAM:87,4df9226063731558172862! 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20110615/9bf163fd/attachment.html>