[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] RE: XSL-FO and Z-index

Subject: Re: [xsl] RE: XSL-FO and Z-index
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 25 Sep 2012 07:21:49 -0400

Just to add, I teach and advise from a specification's perspective and propose standards-based solutions. Every vendor's tool is different and I cannot guess each mail list reader's overall requirements. If a vendor's extension offers improvements, then the user should weigh the benefit to their solution ... XSL was designed to support extensions for this very reason.

I trust Kevin's feedback in this regard and have done so for many years ... I am not an implementer and he is. I continue to focus on the specifications that I teach, and I'll willingly turn to him when I want to know what more is available beyond the specification. And when comparing the performance of two standards-based solutions that produce a given desired result.

Thank you, as always, Kevin!

. . . . . . . . Ken

At 2012-09-24 23:02 -0700, Kevin Brown wrote:

I am only very sensitive because for many years, many (in my opinion anti
xml/xsl) companies beat down XSL FO solutions in print situations because of
the very thing you brought up. They claimed "non-perfomance" of XSL FO print
engines when in fact their products performed the same as XSL FO solutions
if one would implement them in the same way as they did their proprietary
solutions. Their solutions would pre-image table borders and spit them out
to the page, just as I have suggested. Many XSL FO folks just did not
consider the consequences of their recommendations in the overall scheme of
things. I would not fault Ken for anything and as Ken can (hopefully) attest
to, he and I are very good friends and have shared plenty of dinners and
wonderful conversations together. He gave you a solution to the issue
presented, one solution that works and if you are only rendering a few pages
here and there, works perfectly.

I just want to be sure that issues presented and solved in this mailing list
take into account *all* the factors of requirements from customers. Not just
"how" can this be done but also "why are we doing it" a particular way. I
would hope that everyone would benefit from such conversation. You need to
consider all of these factors and do what is right for yourself and/or your

I presented you real facts. Imaging a table as cells in one document,
occasionally, is nothing. Great, do it that way.

But if you are doing it in 100,000 documents in a short period of time, you
better change your methods now. You are screwed otherwise because any
formatting engine drawing that many lines and any printer instructed to draw
that many lines, well, the outcome is obvious.

Actual in practice implementations of XSL FO can teach folks a lot about
what to do and not what to do. All folks need to do is ask.

Kevin Brown

Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

Current Thread