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:
Jesper:
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
customers.
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
RenderX
--
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(_at_)CraneSoftwrights(_dot_)com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--