You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by David Wood <ob...@panix.com> on 2002/02/24 03:35:32 UTC

Re: Linefeed problems / Baseline-to-baseline

I have an MS SQL Server database which is producing XML output via FOR
XML. My aim is to produce PDF documents "on demand" using this XML
output.

The data includes newlines, which are now being ignored.  :) It also
contains some XML (including <P>...</P> tags to delimit paragraphs); this
XML is escaped by the database as I receive it.

While it is cumbersome and I would prefer not to, I can make an extra step
and unescape the the tags before FOP sees the XML; then I can use the
template to convert them into blocks and recover my paragraph breaks.

It would be especially clever if there was some method of unescaping text
and then processing newly uncovered elements in XSLT, but after some
study, I'm at a loss for how that would be possible. So I have to do it
"on the outside." Hardly a big programming challenge.  :)

Obviously it would be nice if the linefeed-treatment attribute worked and
I could skip this altogether, but c'est la vie...

My other issue right at the moment has to do with recreating
"baseline-to-basline" spacing, which I'm starting to think _might_ be
possible in FO, but can't be done in FOP (because line-height and/or
text-altitude don't seem work on inline or character elements).

-David

On Sat, 23 Feb 2002, Carlos wrote:

> What is it that you're trying to do? Perhaps we can provide suggestions
>
> On 02/23/02 16:40, "David Wood" <ob...@panix.com> wrote:
>
> > Thanks for your reply! I will find a way to unescape my paragraph tags;
> > that should solve my problem.
> >
> > Best regards,
> > -David
> >
> > On Sat, 23 Feb 2002, Carlos wrote:
> >
> >> Nope, not with the current FOP implementations.
> >>
> >> Carlos
> >>
> >> On 02/22/02 22:07, "David Wood" <ob...@panix.com> wrote:
> >>
> >>> Using FOP 0.20.2 I found that linefeeds were preserved by default in
> >>> blocks.
> >>>
> >>> Using FOP 0.20.3rc2 I found that they are no longer preserved.
> >>> Furthermore, I discovered that "linefeed-treatement" has no effect:
> >>>
> >>> [WARN]: property - "linefeed-treatment" is not implemented yet.
> >>>
> >>> Is there any way to preserve linefeeds in the current version? I pull text
> >>> from the database in such a way that all integral XML is escaped, and
> >>> there is no way to disable this feature (MS at work)... So I actually have
> >>> <P>...</P> tags, but they're escaped, and I can't seem to find a method in
> >>> XSLT to unescape and use them...
> >>>
> >>> This leaves me stumped. So what's the newline situation?
> >>>
> >>> -David
> >>>
> >>
> >> --
> >> Carlos E. Araya
> >> ---+ WebCT Administrator/Trainer
> >>  P | California Virtual Campus
> >>  - | C/O De Anza College
> >>  G | 21250 Stevens Creek Blvd
> >> ---+ Cupertino, CA 95014
> >>
> >> email               carlos@cvc.edu
> >> web                 http://www.cvc1.org/ (work)
> >>                     http://www.silverwolf-net.net (personal)
> >> phone               408 257 0420 (work)
> >> PGP Fingerprint:    E629 5DFD 7EAE 4995 E9D7  3D2F 5A9F 0CE7 DFE7 1756
> >>
> >> 80/20 Rule: Simplicity vs. complexity. 80 percent of the
> >> functionality/feature set of an "ideal" solution set, with only 20 percent
> >> of the complexity of the ideal solution or 20 percent of the effort required
> >> to build the ideal solution; or put another way, the last 20 percent of the
> >> "ideal" feature set is what creates the most complexity
> >>
> >
> >
>
> --
> Carlos E. Araya
> ---+ WebCT Administrator/Trainer
>  P | California Virtual Campus
>  - | C/O De Anza College
>  G | 21250 Stevens Creek Blvd
> ---+ Cupertino, CA 95014
>
> email               carlos@cvc.edu
> web                 http://www.cvc1.org/ (work)
>                     http://www.silverwolf-net.net (personal)
> phone               408 257 0420 (work)
> PGP Fingerprint:    E629 5DFD 7EAE 4995 E9D7  3D2F 5A9F 0CE7 DFE7 1756
>
> Hey! It compiles! Ship it!
>



Re: Linefeed problems / Baseline-to-baseline

Posted by Carlos <ca...@cvc.edu>.
On 02/23/02 19:44, "David Wood" <ob...@panix.com> wrote:

> On Sat, 23 Feb 2002, Carlos wrote:
> 
>>> While it is cumbersome and I would prefer not to, I can make an extra step
>>> and unescape the the tags before FOP sees the XML; then I can use the
>>> template to convert them into blocks and recover my paragraph breaks.
>> One solution would be to use another XSLT stylesheet to do this: Have an
>> XSLT stlyle sheet that detects paragraphs and copies everything else to the
>> target document.
> 
> Hmm... Do you mean do two separate processing steps - i.e. one with a
> secondary XSLT processor, and then the next with FOP? Not such a bad
> thought.  :)
As a matter of fact, you can incorporate both XSLT and FO on the same
stylesheet. A good example of how that is done is Norman Walsh's Docbook XSL
and XSL:FO stylesheets. If Interested you can download them from
http://sourceforge.net/projects/docbook

You can do it with one or two steps, depending on maintenance needs and how
have you structured your documents and stylesheets

> 
>>> Obviously it would be nice if the linefeed-treatment attribute worked and
>>> I could skip this altogether, but c'est la vie...
>> It's part of the standard so it'll be supported before 1.0 is released. Any
>> help is welcome
> 
> I would be eager to contribute to this (excellent) project - but I
> understand that the team is engaged in a rewrite, so any work on the
> current Java code would be lost. Meanwhile, I have the vague impression
> the rewrite is not far along enough yet for a stranger like me to jump in
> and do more good than harm.
> 
> Perhaps I am mistaken?
I'll defer to others for the answer to that, but my thought is that it's
always better to have something to modify rather than starting from scratch.

> 
>>> My other issue right at the moment has to do with recreating
>>> "baseline-to-basline" spacing, which I'm starting to think _might_ be
>>> possible in FO, but can't be done in FOP (because line-height and/or
>>> text-altitude don't seem work on inline or character elements).
>> If you can dedicate budget to it, look at RenderX, they are pricey but
>> support more of the XSL standard than FOP does at this time
> 
> Thank you very much for this advice. I have looked at RenderX/XEP; they do
> have a very impressive degree of completeness, and you are right, they are
> extremely expensive. As I am targeting a dual-CPU Wintel server, a XEP
> licence would run me 10 large, well beyond what I can afford.  :(
> 
> It's OK. Both of these (no newlines and no baseline-to-baseline) are an
> inconvenience, but they are problems I can work around.
> 
> -David
> 

-- 
Carlos E. Araya
---+ WebCT Administrator/Trainer
 P | California Virtual Campus
 - | C/O De Anza College
 G | 21250 Stevens Creek Blvd
---+ Cupertino, CA 95014

email               carlos@cvc.edu
web                 http://www.cvc1.org/ (work)
                    http://www.silverwolf-net.net (personal)
phone               408 257 0420 (work)
PGP Fingerprint:    E629 5DFD 7EAE 4995 E9D7  3D2F 5A9F 0CE7 DFE7 1756

We cannot put off living until we are ready. The most salient
characteristic of life is its  coerciveness: it is always urgent,  'here and
now' without any possible postponement. Life is  fired at us point blank.
Jose Ortega Y Gasset



Re: Linefeed problems / Baseline-to-baseline

Posted by David Wood <ob...@panix.com>.
On Sat, 23 Feb 2002, Carlos wrote:

> > While it is cumbersome and I would prefer not to, I can make an extra step
> > and unescape the the tags before FOP sees the XML; then I can use the
> > template to convert them into blocks and recover my paragraph breaks.
> One solution would be to use another XSLT stylesheet to do this: Have an
> XSLT stlyle sheet that detects paragraphs and copies everything else to the
> target document.

Hmm... Do you mean do two separate processing steps - i.e. one with a
secondary XSLT processor, and then the next with FOP? Not such a bad
thought.  :)

> > Obviously it would be nice if the linefeed-treatment attribute worked and
> > I could skip this altogether, but c'est la vie...
> It's part of the standard so it'll be supported before 1.0 is released. Any
> help is welcome

I would be eager to contribute to this (excellent) project - but I
understand that the team is engaged in a rewrite, so any work on the
current Java code would be lost. Meanwhile, I have the vague impression
the rewrite is not far along enough yet for a stranger like me to jump in
and do more good than harm.

Perhaps I am mistaken?

> > My other issue right at the moment has to do with recreating
> > "baseline-to-basline" spacing, which I'm starting to think _might_ be
> > possible in FO, but can't be done in FOP (because line-height and/or
> > text-altitude don't seem work on inline or character elements).
> If you can dedicate budget to it, look at RenderX, they are pricey but
> support more of the XSL standard than FOP does at this time

Thank you very much for this advice. I have looked at RenderX/XEP; they do
have a very impressive degree of completeness, and you are right, they are
extremely expensive. As I am targeting a dual-CPU Wintel server, a XEP
licence would run me 10 large, well beyond what I can afford.  :(

It's OK. Both of these (no newlines and no baseline-to-baseline) are an
inconvenience, but they are problems I can work around.

-David


Re: Linefeed problems / Baseline-to-baseline

Posted by Carlos <ca...@cvc.edu>.
On 02/23/02 18:35, "David Wood" <ob...@panix.com> wrote:

<snip/>
> 
> The data includes newlines, which are now being ignored.  :) It also
> contains some XML (including <P>...</P> tags to delimit paragraphs); this
> XML is escaped by the database as I receive it.
> 
> While it is cumbersome and I would prefer not to, I can make an extra step
> and unescape the the tags before FOP sees the XML; then I can use the
> template to convert them into blocks and recover my paragraph breaks.
One solution would be to use another XSLT stylesheet to do this: Have an
XSLT stlyle sheet that detects paragraphs and copies everything else to the
target document.


<snip/>

> 
> Obviously it would be nice if the linefeed-treatment attribute worked and
> I could skip this altogether, but c'est la vie...
It's part of the standard so it'll be supported before 1.0 is released. Any
help is welcome

> 
> My other issue right at the moment has to do with recreating
> "baseline-to-basline" spacing, which I'm starting to think _might_ be
> possible in FO, but can't be done in FOP (because line-height and/or
> text-altitude don't seem work on inline or character elements).
If you can dedicate budget to it, look at RenderX, they are pricey but
support more of the XSL standard than FOP does at this time

Carlos

> 
> -David
> 
> On Sat, 23 Feb 2002, Carlos wrote:
> 
>> What is it that you're trying to do? Perhaps we can provide suggestions
>> 
>> On 02/23/02 16:40, "David Wood" <ob...@panix.com> wrote:
>> 
>>> Thanks for your reply! I will find a way to unescape my paragraph tags;
>>> that should solve my problem.
>>> 
>>> Best regards,
>>> -David
>>> 
>>> On Sat, 23 Feb 2002, Carlos wrote:
>>> 
>>>> Nope, not with the current FOP implementations.
>>>> 
>>>> Carlos
>>>> 
>>>> On 02/22/02 22:07, "David Wood" <ob...@panix.com> wrote:
>>>> 
>>>>> Using FOP 0.20.2 I found that linefeeds were preserved by default in
>>>>> blocks.
>>>>> 
>>>>> Using FOP 0.20.3rc2 I found that they are no longer preserved.
>>>>> Furthermore, I discovered that "linefeed-treatement" has no effect:
>>>>> 
>>>>> [WARN]: property - "linefeed-treatment" is not implemented yet.
>>>>> 
>>>>> Is there any way to preserve linefeeds in the current version? I pull text
>>>>> from the database in such a way that all integral XML is escaped, and
>>>>> there is no way to disable this feature (MS at work)... So I actually have
>>>>> <P>...</P> tags, but they're escaped, and I can't seem to find a method in
>>>>> XSLT to unescape and use them...
>>>>> 
>>>>> This leaves me stumped. So what's the newline situation?
>>>>> 
>>>>> -David
>>>>> 
>>>> 
>>>> --
>>>> Carlos E. Araya
>>>> ---+ WebCT Administrator/Trainer
>>>>  P | California Virtual Campus
>>>>  - | C/O De Anza College
>>>>  G | 21250 Stevens Creek Blvd
>>>> ---+ Cupertino, CA 95014
>>>> 
>>>> email               carlos@cvc.edu
>>>> web                 http://www.cvc1.org/ (work)
>>>>                     http://www.silverwolf-net.net (personal)
>>>> phone               408 257 0420 (work)
>>>> PGP Fingerprint:    E629 5DFD 7EAE 4995 E9D7  3D2F 5A9F 0CE7 DFE7 1756
>>>> 
>>>> 80/20 Rule: Simplicity vs. complexity. 80 percent of the
>>>> functionality/feature set of an "ideal" solution set, with only 20 percent
>>>> of the complexity of the ideal solution or 20 percent of the effort
>>>> required
>>>> to build the ideal solution; or put another way, the last 20 percent of the
>>>> "ideal" feature set is what creates the most complexity
>>>> 
>>> 
>>> 
>> 
>> --
>> Carlos E. Araya
>> ---+ WebCT Administrator/Trainer
>>  P | California Virtual Campus
>>  - | C/O De Anza College
>>  G | 21250 Stevens Creek Blvd
>> ---+ Cupertino, CA 95014
>> 
>> email               carlos@cvc.edu
>> web                 http://www.cvc1.org/ (work)
>>                     http://www.silverwolf-net.net (personal)
>> phone               408 257 0420 (work)
>> PGP Fingerprint:    E629 5DFD 7EAE 4995 E9D7  3D2F 5A9F 0CE7 DFE7 1756
>> 
>> Hey! It compiles! Ship it!
>> 
> 
> 

-- 
Carlos E. Araya
---+ WebCT Administrator/Trainer
 P | California Virtual Campus
 - | C/O De Anza College
 G | 21250 Stevens Creek Blvd
---+ Cupertino, CA 95014

email               carlos@cvc.edu
web                 http://www.cvc1.org/ (work)
                    http://www.silverwolf-net.net (personal)
phone               408 257 0420 (work)
PGP Fingerprint:    E629 5DFD 7EAE 4995 E9D7  3D2F 5A9F 0CE7 DFE7 1756

"Come to think of it, there already are a million monkeys at a
million typewriters, and usenet is _NOTHING_ like Shakespeare." -
Blair Houghton.