All--
Easy now. This is just a discussion, not a personal challenge to anyone :-) I have no beef with XEP. In fact, I use it and recommend it highly. In almost every respect it is far superior to FOP and is, as you all say, a completely professional product. You are correct that the OT's stylesheets are the underlying problem here and in fact, I discovered a workaround that I just posted to the DITA Users list.
Apologies if my previous post seemed to suggest the integrity of XEP should be compromised. The workaround I posted gets at the real heart of the problem (the stylesheets) and so it seems there is a solution we can all be happy with.
Best,
Leigh
> From: xep-support-request@renderx.com
> Subject: Xep-support Digest, Vol 9, Issue 13
> To: xep-support@renderx.com
> Date: Wed, 15 Jun 2011 15:13:48 -0700
>
> Send Xep-support mailing list submissions to
> xep-support@renderx.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.renderx.com/mailman/listinfo/xep-support
> or, via email, send a message with subject or body 'help' to
> xep-support-request@renderx.com
>
> You can reach the person managing the list at
> xep-support-owner@renderx.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xep-support digest..."
>
>
> Today's Topics:
>
> 1. Re: table column widths correct in FOP but not in XEP (LW White)
> 2. Re: table column widths correct in FOP but not in XEP
> (Kevin Brown)
> 3. Re: table column widths correct in FOP but not in XEP
> (G. Ken Holman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Jun 2011 16:21:28 -0500
> From: LW White <lwwhite5@hotmail.com>
> To: XEP Support <xep-support@renderx.com>
> Subject: [xep-support] Re: table column widths correct in FOP but not
> in XEP
> Message-ID: <BLU144-W166B5635B3116742C9C471866B0@phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> 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
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20110615/c9563c5f/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 15 Jun 2011 14:42:12 -0700
> From: "Kevin Brown" <kevin@renderx.com>
> To: "'RenderX Community Support List'" <xep-support@renderx.com>
> Subject: [xep-support] Re: table column widths correct in FOP but not
> in XEP
> Message-ID: <04c701cc2ba5$16378fc0$42a6af40$@com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> ? 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@renderx.com
> [mailto:xep-support-bounces@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-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 15 Jun 2011 18:11:59 -0400
> From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
> To: RenderX Community Support List <xep-support@renderx.com>
> Subject: [xep-support] Re: table column widths correct in FOP but not
> in XEP
> Message-ID: <7.0.1.0.2.20110615175711.0256bc20@wheresmymailserver.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 2011-06-15 16:21 -0500, LW White wrote:
> >my interpretation is that if the @width value is greater than the
> >sum of the column widths, use that and enlarge the columns accordingly..
>
> Yes, that is what the specification requires ... no room for doubt:
>
> "If the table is wider than the columns, the extra space
> should be distributed over the columns."
>
> >This seems to be a fundamental usability flaw in the spec.
>
> Not at all! If a user decides to overconstrain the geometry, the
> specification should document a consistent behaviour for all
> conforming processors, and so it does.
>
> You are witnessing a flaw in the stylesheets! By what principle is
> this a flaw in the specification? The designers had to make a
> decision, they made one, it is now being implemented by conforming
> tools. This is just evidence that whoever wrote your stylesheets
> didn't read the specification in this regard.
>
> >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.
>
> Surely you mean "revisit the DITA stylesheets". If the DITA
> stylesheet is not giving the users what they need, change the
> incorrect stylesheet.
>
> >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!
>
> I'll say "by accident". Surely a user community cannot *expect* a
> commercial tool to be non-conformant.
>
> This is not the first case I've heard of where the OT is not meeting
> user expectations. My DITA customer had me write all their
> stylesheets from scratch and XEP is doing a wonderful job with my
> stylesheets for them.
>
> I have no commercial involvement in RenderX so I'm writing this
> purely from the perspective of a developer in the community as an
> arm's-length professional opinion. If a tool is not conformant, I'm
> not going to use it or advise my customers to use it. People keep
> telling me that FOP is "professional" but I do not say that about FOP
> because I've *never* been able to use it for my paying customers.
>
> RenderX tools are very professional products. You get what you pay for!
>
> As a developer I think it is out of order for a user to ask a vendor
> to implement a "bug emulation mode" of someone else's problem.
>
> . . . . . . . . . . Ken
>
>
> --
> Contact us for world-wide XML consulting & instructor-led training
> Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/
> G. Ken Holman mailto:gkholman@CraneSoftwrights.com
> Legal business disclaimers: http://www.CraneSoftwrights.com/legal
>
>
> !DSPAM:87,4df92e9063731092011399!
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xep-support mailing list
> Xep-support@renderx.com
> http://lists.renderx.com/mailman/listinfo/xep-support
>
>
> End of Xep-support Digest, Vol 9, Issue 13
> ******************************************
!DSPAM:87,4df9330763739047622087!
_______________________________________________
(*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support
(*) By using the Service, you expressly agree to these Terms of Service http://w
ww.renderx.com/terms-of-service.html
Received on Wed Jun 15 15:32:51 2011
This archive was generated by hypermail 2.1.8 : Wed Jun 15 2011 - 15:32:53 PDT