You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Rachael Blank <bl...@mars-systems.com> on 2001/11/02 18:16:03 UTC
FOP: Critical Problem
Hello!
I have seen many posts regarding the lack of support of the
linefeed-preserve tag. Since August, I have been corresponding with one
of the FOP Independent Members of the Apache Software Foundation, Arved
Sandstrom, to get this problem resolved.
We have had no success to date. We have a critical application that
relies on this functionality. This will be used by over 5,000
Cariologists. This is a fairly sophisticated application which enables
doctors to view, edit and then print a final copy of their
transcriptions. It will enable the success of our company and also be a
great benchmark for the FOP technology. We are ready to roll out the
application once this is completed.
We would greatly appreciate any help to get this feature working. Our
java programmers would be willing to work closely with your team to get
this issue resolved.
Thank you kindly,
Rachael Blank
Medical Archival Systems, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOP: Critical Problem
Posted by Matt Savino <ma...@synergizethis.com>.
Rachael, sounds interesting. I'm guessing you're using an XSLT
stylesheet to convert the XML you receive either to HTML or FO--which
then goes into FOP and comes out PDF. Is that right? If so, I'm still
not sure why you couldn't put some extra logic in that stylesheet. I'd
also be very intersted in anything you can say about how you're
implementing the edit feature.
Here's what we're doing:
Our application is a mostly read-only internet reporting application
that provides ongoing lab results and some canned management reports to
our clinical trials customers. We plan to add more features in the
future. (I don't think I'm giving away anything here.) We get the data
for a given report from Oracle (incremental data is received from a
MUMPS system and fed to Oracle 8 times a day) by executing stored
procedures which can return any number of result sets representing
levels in the data (study, doctor, patient, visit, test, etc...). We
convert these result-sets straight into XML using the built in Oracle
tool. Then we have a Java piece which combines the flat-strucuted XML
result-sets into one XML document(report) which reflects the structure
of the data. The nice part about this piece is that it gets specific
instructions about how to assmeble each report from a fairly
straightforward XML template. Finally we use a collection of
report-specific XSLT stylesheets to convert the report XML into FO->PDF,
HTML, or delimited text. The end user can also request data in straight
XML, though we doubt any of our customers will be ready for that for a
while. The nice part about the tailored structure of the XML is that the
stylesheets come out very simple, mostly just dropping from one template
to the next.
We've tried to relegate report-specific logic to a few places, keeping
data-manipulation in the data layer (the stored procs), presentation in
the stylesheets, and have the Java piece be essentially a dumb conduit.
But as always we've had to cheat a little here and there. I've
discovered that you can do almost anything in a stylesheet, it's just a
matter of how much you want to complicate things. For instance, in one
of the reports we're doing a full transpose of row data into columns,
with a break at every fifth column. IE - the first set of columns could
take up 3 pages, with columns 6-10 starting at page 4. We decided to put
this piece in the stylesheet because the number of columns printed
varies, which makes defining a result-set that emulates the report
difficult (the max number of columns is technically 9,999 - don't ask).
But in practice the max number of columns and rows is low (20/100), so
we don't have to worry about XSLT memory or performance issues arising
from the transpose. On that note, we've also discovered that when the
report XML is already in a fairly pristine data structure, the
stylesheet seems to have no issues rendering some of our other reports
which can get huge. On large reports, the FOP transformation, stored
proc call, and Oracle XML conversion all take longer than the XSLT piece
by a factor of 10.
So anyway, if you really can't do anything special before your data gets
to FOP I guess you can either wait for these guys to implement
linefeed-treatment="preserve" or try to write your own extension. Like I
said I've got an extension I need to create. But I've got a million
little loose ends to tie up before I start on it.
Just out of curiosity has anyone ever offered the active FOP developers
money to work faster or on a specific piece? I can't imagine trying to
convince my company to shell out $50k for something like this, even if
it would save them a million in the long run. It just wouldn't compute.
But $50k for third-party penetration testing, where they come back with
pearls like "Use POST instead of GET"??? - No problem.
Sorry guys.
Matt
Rachael Blank wrote:
>
> Matt,
>
> Thanks again for your help. I haven't gotten it to work yet, but I am still
> plugging away at it.
>
> As a developer in the healthcare industry, I can understand your curiousity.
>
> My company handles the archival of millions of records at UPMC. Essentially, we
> parse disparate data and archive it so that users can access data from different
> systems in one place. Great idea...huh?
>
> We have a subsidiary company which offers a transcription service, Scribes
> Online. It is an Internet-based transcription service for which I developed the
> interim solution for the online retrieval of their physician's dictations. There
> is currently now a small team of us who are wrapping up development of the
> replacement to my interim solution. The only road block seems to be the
> linefeed-preserve issue.
>
> I can't get into details without breeching non-disclosure agreements and such, but
> here it is...
> A Physican dictates a report via phone
> The Medical Trancriptionist transcribes the document into an application which
> feeds into Oracle.
> We pull the document from Oracle using JSP and servlets. The XML is generated on
> the fly with JSP.
> (Up until this point I am not involved in development)
> I am on the Web GUI side where I create stylesheets that enable the physician to
> edit, view a "read only" copy and/or print a final PDF copy of the document.
> We also offer a batch printing, sorting and searching capabilities.
>
> After a certain period of time specified by the client, we archive the data and
> can do very detailed and advanced analysis for the client.
>
> We would sincerely appreciate any more help with this issue. It would be a
> terrible shame for us and FOP for the project to go BUST.
>
> Thanks again!
>
> Rachael
>
> Matt Savino wrote:
>
> > I work for a giant healthcare company, and it's still hard for me to
> > imagine how the data comes from --somewhere-- then is inserted into an
> > fo: document with no chance for any text manipulation. Not saying I
> > don't believe it, Id just love to hear the situation.
> >
> > So what about some kind of quick n' dirty little extension to do the
> > work until linespace-treatment="preserve" is implemented. (Is it in the
> > plans to attempt to implement everything in the FO spec?) I haven't
> > started on my table-header with (Cont) extension yet, but when I do I'll
> > let the group know how it goes.
> >
> > Arved Sandstrom wrote:
> > >
> > > At 09:52 AM 11/2/01 -0800, you wrote:
> > > >Our application also needs linefeeds preserved in certain cases. We
> > > >convert them at the stylesheet level. Here's how we do it:
> > > [ SNIP ]
> > > >Like I said, I have no idea if you're even using stylesheets. I have a
> > > >feeling if you're talking with Arved, this avenue has already been
> > > >explored. But I figured I'd throw it out there just in case. By the way
> > > >if anyone knows of a slicker method to do what I'm doing above (ie some
> > > >sort of Perl-style replace, or Java-style string tokenizer
> > > >functionality), please chime in.
> > >
> > > This possibility, or something essentially similar, came up. That is, I
> > > suggested a workaround. Rachael explained the production scenario, and it
> > > appears to make sense to me that extra processing of the content before it
> > > gets to the formatter is not acceptable. So unless something has changed we
> > > are definitely talking about source code changes.
> > >
> > > I did Rachael a disservice by underestimating the scope of the fix (I looked
> > > at the FOP code and started working on this, and it wasn't so
> > > straightforward) and overestimating the amount of time I had available to do
> > > something about it. Work at my last company was pretty crazy for a lot of
> > > this year, and I should have taken that into account, and I apologize for
> > > being naively optimistic. In any case that last company has now folded and
> > > at the moment I am _not_ in a position to assist. :-)
> > >
> > > Regards,
> > > Arved Sandstrom
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: fop-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> > For additional commands, email: fop-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOP: Critical Problem
Posted by Rachael Blank <bl...@mars-systems.com>.
Matt,
Thanks again for your help. I haven't gotten it to work yet, but I am still
plugging away at it.
As a developer in the healthcare industry, I can understand your curiousity.
My company handles the archival of millions of records at UPMC. Essentially, we
parse disparate data and archive it so that users can access data from different
systems in one place. Great idea...huh?
We have a subsidiary company which offers a transcription service, Scribes
Online. It is an Internet-based transcription service for which I developed the
interim solution for the online retrieval of their physician's dictations. There
is currently now a small team of us who are wrapping up development of the
replacement to my interim solution. The only road block seems to be the
linefeed-preserve issue.
I can't get into details without breeching non-disclosure agreements and such, but
here it is...
A Physican dictates a report via phone
The Medical Trancriptionist transcribes the document into an application which
feeds into Oracle.
We pull the document from Oracle using JSP and servlets. The XML is generated on
the fly with JSP.
(Up until this point I am not involved in development)
I am on the Web GUI side where I create stylesheets that enable the physician to
edit, view a "read only" copy and/or print a final PDF copy of the document.
We also offer a batch printing, sorting and searching capabilities.
After a certain period of time specified by the client, we archive the data and
can do very detailed and advanced analysis for the client.
We would sincerely appreciate any more help with this issue. It would be a
terrible shame for us and FOP for the project to go BUST.
Thanks again!
Rachael
Matt Savino wrote:
> I work for a giant healthcare company, and it's still hard for me to
> imagine how the data comes from --somewhere-- then is inserted into an
> fo: document with no chance for any text manipulation. Not saying I
> don't believe it, Id just love to hear the situation.
>
> So what about some kind of quick n' dirty little extension to do the
> work until linespace-treatment="preserve" is implemented. (Is it in the
> plans to attempt to implement everything in the FO spec?) I haven't
> started on my table-header with (Cont) extension yet, but when I do I'll
> let the group know how it goes.
>
> Arved Sandstrom wrote:
> >
> > At 09:52 AM 11/2/01 -0800, you wrote:
> > >Our application also needs linefeeds preserved in certain cases. We
> > >convert them at the stylesheet level. Here's how we do it:
> > [ SNIP ]
> > >Like I said, I have no idea if you're even using stylesheets. I have a
> > >feeling if you're talking with Arved, this avenue has already been
> > >explored. But I figured I'd throw it out there just in case. By the way
> > >if anyone knows of a slicker method to do what I'm doing above (ie some
> > >sort of Perl-style replace, or Java-style string tokenizer
> > >functionality), please chime in.
> >
> > This possibility, or something essentially similar, came up. That is, I
> > suggested a workaround. Rachael explained the production scenario, and it
> > appears to make sense to me that extra processing of the content before it
> > gets to the formatter is not acceptable. So unless something has changed we
> > are definitely talking about source code changes.
> >
> > I did Rachael a disservice by underestimating the scope of the fix (I looked
> > at the FOP code and started working on this, and it wasn't so
> > straightforward) and overestimating the amount of time I had available to do
> > something about it. Work at my last company was pretty crazy for a lot of
> > this year, and I should have taken that into account, and I apologize for
> > being naively optimistic. In any case that last company has now folded and
> > at the moment I am _not_ in a position to assist. :-)
> >
> > Regards,
> > Arved Sandstrom
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> > For additional commands, email: fop-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOP: Critical Problem
Posted by Matt Savino <ma...@synergizethis.com>.
I work for a giant healthcare company, and it's still hard for me to
imagine how the data comes from --somewhere-- then is inserted into an
fo: document with no chance for any text manipulation. Not saying I
don't believe it, Id just love to hear the situation.
So what about some kind of quick n' dirty little extension to do the
work until linespace-treatment="preserve" is implemented. (Is it in the
plans to attempt to implement everything in the FO spec?) I haven't
started on my table-header with (Cont) extension yet, but when I do I'll
let the group know how it goes.
Arved Sandstrom wrote:
>
> At 09:52 AM 11/2/01 -0800, you wrote:
> >Our application also needs linefeeds preserved in certain cases. We
> >convert them at the stylesheet level. Here's how we do it:
> [ SNIP ]
> >Like I said, I have no idea if you're even using stylesheets. I have a
> >feeling if you're talking with Arved, this avenue has already been
> >explored. But I figured I'd throw it out there just in case. By the way
> >if anyone knows of a slicker method to do what I'm doing above (ie some
> >sort of Perl-style replace, or Java-style string tokenizer
> >functionality), please chime in.
>
> This possibility, or something essentially similar, came up. That is, I
> suggested a workaround. Rachael explained the production scenario, and it
> appears to make sense to me that extra processing of the content before it
> gets to the formatter is not acceptable. So unless something has changed we
> are definitely talking about source code changes.
>
> I did Rachael a disservice by underestimating the scope of the fix (I looked
> at the FOP code and started working on this, and it wasn't so
> straightforward) and overestimating the amount of time I had available to do
> something about it. Work at my last company was pretty crazy for a lot of
> this year, and I should have taken that into account, and I apologize for
> being naively optimistic. In any case that last company has now folded and
> at the moment I am _not_ in a position to assist. :-)
>
> Regards,
> Arved Sandstrom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOP: Critical Problem
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 09:52 AM 11/2/01 -0800, you wrote:
>Our application also needs linefeeds preserved in certain cases. We
>convert them at the stylesheet level. Here's how we do it:
[ SNIP ]
>Like I said, I have no idea if you're even using stylesheets. I have a
>feeling if you're talking with Arved, this avenue has already been
>explored. But I figured I'd throw it out there just in case. By the way
>if anyone knows of a slicker method to do what I'm doing above (ie some
>sort of Perl-style replace, or Java-style string tokenizer
>functionality), please chime in.
This possibility, or something essentially similar, came up. That is, I
suggested a workaround. Rachael explained the production scenario, and it
appears to make sense to me that extra processing of the content before it
gets to the formatter is not acceptable. So unless something has changed we
are definitely talking about source code changes.
I did Rachael a disservice by underestimating the scope of the fix (I looked
at the FOP code and started working on this, and it wasn't so
straightforward) and overestimating the amount of time I had available to do
something about it. Work at my last company was pretty crazy for a lot of
this year, and I should have taken that into account, and I apologize for
being naively optimistic. In any case that last company has now folded and
at the moment I am _not_ in a position to assist. :-)
Regards,
Arved Sandstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOP: Critical Problem
Posted by Keiron Liddle <ke...@aftexsw.com>.
Hello Rachael,
I would consider the implementation of such a feature to be fairly simple.
Writing the code to implement the feature is another matter.
The approach currently being taken with FOP is to have a solid approach to
the design from the top down. When this is done properly then individual
features should be relatively easy to implement.
If you really want to get such a feature implemented then it is best to
take a broad view on the problem. Ultimately we want FOP to implement the
complete set of features described in the specification. To achieve this we
need to have a design and approach that will eventually lead to all
features being implemented in the simplest way. So if you want the
development of FOP to lead to the implementation of your required feature
then I would suggest getting involved with areas of the program that will
help in the development.
For example the linefeed-preserve is part of the line creation process. If
you can help with the development of the conversion from certain formatting
objects to the creation of line areas then I am sure it will lead to the
development of the feature.
Regards,
Keiron Liddle.
On 2001.11.02 18:16 Rachael Blank wrote:
> Hello!
>
> I have seen many posts regarding the lack of support of the
> linefeed-preserve tag. Since August, I have been corresponding with one
> of the FOP Independent Members of the Apache Software Foundation, Arved
> Sandstrom, to get this problem resolved.
>
> We have had no success to date. We have a critical application that
> relies on this functionality. This will be used by over 5,000
> Cariologists. This is a fairly sophisticated application which enables
> doctors to view, edit and then print a final copy of their
> transcriptions. It will enable the success of our company and also be a
> great benchmark for the FOP technology. We are ready to roll out the
> application once this is completed.
>
> We would greatly appreciate any help to get this feature working. Our
> java programmers would be willing to work closely with your team to get
> this issue resolved.
>
> Thank you kindly,
>
> Rachael Blank
> Medical Archival Systems, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOP: Critical Problem
Posted by Matt Savino <ma...@synergizethis.com>.
Our application also needs linefeeds preserved in certain cases. We
convert them at the stylesheet level. Here's how we do it:
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:fo="http://www.w3.org/1999/XSL/Format">
<...>
<fo:block text-align="start" font-size="8pt">
<xsl:call-template name="setNewLine">
<xsl:with-param name="string" select="@RSLT_CMT"/>
</xsl:call-template>
</fo:block>
<...>
<xsl:template name="setNewLine">
<fo:block>
<xsl:param name="string" />
<xsl:if test="contains($string, '^')">
<xsl:value-of select="substring-before($string, '^')" />
<xsl:call-template name="setNewLine">
<xsl:with-param name="string" select="substring-after($string, '^')"
/>
</xsl:call-template>
</xsl:if>
<xsl:if test="not(contains($string, '^'))">
<xsl:value-of select="$string" />
</xsl:if>
</fo:block>
</xsl:template>
</xsl:stylesheet>
Actually I just realized we're replacing line feeds with '^'s earlier in
the process. But I assume you could match the unicode character for
newline here instead. Basically, the remplate just wraps a <block> tag
around the substring it finds up to '^', then recursively loops through
the remaining substring until it's done.
Like I said, I have no idea if you're even using stylesheets. I have a
feeling if you're talking with Arved, this avenue has already been
explored. But I figured I'd throw it out there just in case. By the way
if anyone knows of a slicker method to do what I'm doing above (ie some
sort of Perl-style replace, or Java-style string tokenizer
functionality), please chime in.
thx,
Matt Savino
Rachael Blank wrote:
>
> Hello!
>
> I have seen many posts regarding the lack of support of the
> linefeed-preserve tag. Since August, I have been corresponding with one
> of the FOP Independent Members of the Apache Software Foundation, Arved
> Sandstrom, to get this problem resolved.
>
> We have had no success to date. We have a critical application that
> relies on this functionality. This will be used by over 5,000
> Cariologists. This is a fairly sophisticated application which enables
> doctors to view, edit and then print a final copy of their
> transcriptions. It will enable the success of our company and also be a
> great benchmark for the FOP technology. We are ready to roll out the
> application once this is completed.
>
> We would greatly appreciate any help to get this feature working. Our
> java programmers would be willing to work closely with your team to get
> this issue resolved.
>
> Thank you kindly,
>
> Rachael Blank
> Medical Archival Systems, Inc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org