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 Vincent Hennebert <vi...@enseeiht.fr> on 2005/11/24 21:00:58 UTC
Text handling in svg files, transcoders
Hi,
I would need some help to understand how transcoders and
text handling within svg should work.
o first, when I try to convert some svg that contains text
into pdf with Batik (1.6), text is always rendered as
strokes, even if it would be possible to render it with
pdf text primitives. Whereas it is said on the Fop website
[1] that normal PDF text is used when possible (I've tried
with the text.svg file provided there). Is that normal?
o the strokeSVGText option seems to have disappeared in Fop
Trunk. It doesn't appear anywhere in the source code,
except in a commented line in PSRenderer.java. Is it
abandoned? Not yet implemented in Trunk?
o the PDFTranscoder.configure method is never called within
Fop, neither by Batik. What is (was) its purpose?
o only the PDFTranscoder is distributed with Batik. Is
the PSTranscoder broken? Should I adapt it to FOrayFont?
Thanks,
Vincent
[1] http://xmlgraphics.apache.org/fop/0.90/graphics.html#svg-pdf-text
Re: Text handling in svg files, transcoders
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 24.11.2005 21:27:28 Jeremias Maerki wrote:
> Hi Vincent
>
> On 24.11.2005 21:00:58 Vincent Hennebert wrote:
> > Hi,
> >
> > I would need some help to understand how transcoders and
> > text handling within svg should work.
> >
> > o first, when I try to convert some svg that contains text
> > into pdf with Batik (1.6), text is always rendered as
> > strokes, even if it would be possible to render it with
> > pdf text primitives. Whereas it is said on the Fop website
> > [1] that normal PDF text is used when possible (I've tried
> > with the text.svg file provided there). Is that normal?
>
> For PDF, this should not be the case. I guess I need to check that again.
> Prior to the 0.90alpha1 release this was fixed by introducing
> PDFBridgeContext. For PostScript, this is the case, yes, because I
> haven't had the time to do the necessary changes, yet.
I've just checked:
- PDFTranscoder has the text bridge enabled and uses text commands for
text where possible.
- The same applies to SVG within XSL-FO (PDFSVGHandler)
- EPSTranscoder has the text bridge enabled but the PSTextPainter has a
bug determining paintable text elements and there's another problem with
the Java2D subsystem which paints all text upside down ATM. Now I
remember that I've started debugging in this area but obviously I didn't
finish.
- For SVG in XSL-FO for PostScript output, the text bridge is currently
inactive so that all text is rendered as shapes. The upside-down effect
doesn't occur in this case.
Good summary for myself when I get back to this. :-)
<snip/>
Jeremias Maerki
Re: Text handling in svg files, transcoders
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
Jeremias Maerki a écrit :
> Hey, allow me some wishful thinking on my part. :-) Look, if FOrayFont
> supports fonts without the need for a PFMReader or a TTFReader then the
> road to "font auto-discovery" is just a very small step. And the former
> is an absolute must. Otherwise, the whole thing is a waste of time. I'm
> not even afraid about the performance penalty of an "auto-discovery"
> feature. If someone points to the system's font directory with 500 fonts
> it's his own fault if the whole thing takes a little time to preload. If
> you don't do auto-discovery, that's fine. I'll do it then. I want it. :-)
Ok, then no problem ;-)
Just wanted to make sure you didn't believe that this functionality was
already existing.
Vincent
Re: Text handling in svg files, transcoders
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hey, allow me some wishful thinking on my part. :-) Look, if FOrayFont
supports fonts without the need for a PFMReader or a TTFReader then the
road to "font auto-discovery" is just a very small step. And the former
is an absolute must. Otherwise, the whole thing is a waste of time. I'm
not even afraid about the performance penalty of an "auto-discovery"
feature. If someone points to the system's font directory with 500 fonts
it's his own fault if the whole thing takes a little time to preload. If
you don't do auto-discovery, that's fine. I'll do it then. I want it. :-)
On 28.11.2005 15:11:11 Vincent Hennebert wrote:
> Jeremias Maerki a écrit :
> > On 25.11.2005 16:25:43 thomas.deweese wrote:
> > <snip/>
> >
> >>>Thomas, what do you think about this topic?
> >>
> >> Well I think that currently the text bridges do a pretty good job
> >>determining if they are capable of drawing text as PDF text and drop
> >>back to curves when needed. I would much rather work on catching cases
> >>where this doesn't work properly than adding another option. Do you
> >>know of cases right now where this doesn't work?
> >
> >
> > Yes, the issue when someone uses custom fonts. Text drawn as shapes uses
> > the AWT font subsystem to get at the fonts while text drawn as text
> > needs FOP's own font subsystem to select/embed the right fonts in the
> > target file. I assume some people would probably prefer to simply have
> > their things as simple as possible and not to have to manage an extra
> > font setup. On the other side, when Vincent is done with his work, we'll
> > have font auto-discovery which will improve the situation a lot.
>
> I'm afraid of what you mean by "font auto-discovery"? FOray doesn't have
> font discovery support. This presents some difficulties as already
> discussed on this list [1].
>
> I don't want to bring bad news, but...
>
> Vincent
>
>
> [1] http://marc.theaimsgroup.com/?l=fop-dev&m=111876477207479&w=2
Jeremias Maerki
Re: Text handling in svg files, transcoders
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
Jeremias Maerki a écrit :
> On 25.11.2005 16:25:43 thomas.deweese wrote:
> <snip/>
>
>>>Thomas, what do you think about this topic?
>>
>> Well I think that currently the text bridges do a pretty good job
>>determining if they are capable of drawing text as PDF text and drop
>>back to curves when needed. I would much rather work on catching cases
>>where this doesn't work properly than adding another option. Do you
>>know of cases right now where this doesn't work?
>
>
> Yes, the issue when someone uses custom fonts. Text drawn as shapes uses
> the AWT font subsystem to get at the fonts while text drawn as text
> needs FOP's own font subsystem to select/embed the right fonts in the
> target file. I assume some people would probably prefer to simply have
> their things as simple as possible and not to have to manage an extra
> font setup. On the other side, when Vincent is done with his work, we'll
> have font auto-discovery which will improve the situation a lot.
I'm afraid of what you mean by "font auto-discovery"? FOray doesn't have
font discovery support. This presents some difficulties as already
discussed on this list [1].
I don't want to bring bad news, but...
Vincent
[1] http://marc.theaimsgroup.com/?l=fop-dev&m=111876477207479&w=2
Re: Text handling in svg files, transcoders
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 25.11.2005 16:25:43 thomas.deweese wrote:
<snip/>
> > Thomas, what do you think about this topic?
>
> Well I think that currently the text bridges do a pretty good job
> determining if they are capable of drawing text as PDF text and drop
> back to curves when needed. I would much rather work on catching cases
> where this doesn't work properly than adding another option. Do you
> know of cases right now where this doesn't work?
Yes, the issue when someone uses custom fonts. Text drawn as shapes uses
the AWT font subsystem to get at the fonts while text drawn as text
needs FOP's own font subsystem to select/embed the right fonts in the
target file. I assume some people would probably prefer to simply have
their things as simple as possible and not to have to manage an extra
font setup. On the other side, when Vincent is done with his work, we'll
have font auto-discovery which will improve the situation a lot. Still I
think it doesn't hurt to have an emergeny fallback just in case.
<snip/>
Jeremias Maerki
Re: Text handling in svg files, transcoders
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
Hi Thomas,
thomas.deweese@kodak.com a écrit :
>>But this doesn't work when I run Fop with the same svg included in an fo
>
> file.
>
>>Am I missing something?
>
> I take it this is an FO with inline SVG consisting of an SVG 'image'
> element referencing the SVG file?
The svg file is referenced by an external-graphic element.
> With the 0.9alpha1 FOP and Batik 1.6
> it turns out this won't work properly. If you bundle Batik from SVN this
> should work.
That's it. It works with the newest versions of Batik and Fop.
Thanks!
Vincent
Re: Text handling in svg files, transcoders
Posted by th...@kodak.com.
Hi Vincent,
Vincent Hennebert <vi...@enseeiht.fr> wrote:
> >>> [...]I try to convert some svg that contains text
> >>> into pdf with Batik (1.6), text is always rendered as
> >>> strokes [...]
> thomas.deweese@kodak.com a écrit :
> > This was broken in the Batik 1.6 release. I am about to
> > incorporate the pdf-transcoder.jar from the 0.9alpha1 FOP
> > release into the Batik SVN repository.
Vincent Hennebert <vi...@enseeiht.fr> wrote on 11/25/2005
02:31:48 PM:
> Ok, when I run the Batik rasterizer with an updated pdf-transcoder.jar
from the
> Trunk I can get text as text.
Good.
> But this doesn't work when I run Fop with the same svg included in an fo
file.
> Am I missing something?
I take it this is an FO with inline SVG consisting of an SVG 'image'
element referencing the SVG file? With the 0.9alpha1 FOP and Batik 1.6
it turns out this won't work properly. If you bundle Batik from SVN this
should work.
The problem is that when you reference an image a new BridgeContext
is constructed. In Batik 1.6 this was done in a few places 'in line'
in the code. Shortly after the 1.6 release this was separated into
two methods (createSubBridgeContext - copies over needed state to sub
Bridge Context, and createBridgeContext which is used to create the
BridgeContext instance that should be used). FOP's new PDFBridgeContext
now implements createBridgeContext to provide the sub context but
unfortunately this method isn't called from Batik 1.6 (I thought it was),
but it is from the SVN version of Batik.
I'm thinking it is time for a Batik 1.6.1 and then hopefully when/if
Fop 0.9alpha2 is released most of these issues will be resolved for people
who only want to point to 'released' versions.
Re: Text handling in svg files, transcoders
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
thomas.deweese@kodak.com a écrit :
> Hi Jeremias, Vincent,
>
>>>I would need some help to understand how transcoders and
>>>text handling within svg should work.
>>>
>>>o first, when I try to convert some svg that contains text
>>> into pdf with Batik (1.6), text is always rendered as
>>> strokes, even if it would be possible to render it with
>>> pdf text primitives.
>
> This was broken in the Batik 1.6 release. I am about to
> incorporate the pdf-transcoder.jar from the 0.9alpha1 FOP
> release into the Batik SVN repository.
Ok, when I run the Batik rasterizer with an updated pdf-transcoder.jar from the
Trunk I can get text as text.
But this doesn't work when I run Fop with the same svg included in an fo file.
Am I missing something?
>>>o only the PDFTranscoder is distributed with Batik. Is
>>> the PSTranscoder broken? Should I adapt it to FOrayFont?
>>
>>It's not broken but has less features and I guess the demand hasn't been
>>that high for pure SVG to EPS conversion. You should treat the
>>EPSTranscoder and the PSTranscoder the same way as the PDFTranscoder.
>>The PSTranscoder has less value than the EPSTranscoders. It was
>>originally intended for use with SVG Print but I never got around to
>>having a closer look at it. If anyone wanted PSTranscoder gone, I
>>wouldn't be upset.
>
> As far as I know no one has ever asked for EPS output from Batik.
Ok, I'll try to convert the [E]PSTranscoders but will leave them as is for now
if I encounter too many difficulties.
Thanks,
Vincent
Re: Text handling in svg files, transcoders
Posted by th...@kodak.com.
Hi Jeremias, Vincent,
Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 11/24/2005 03:27:28 PM:
> On 24.11.2005 21:00:58 Vincent Hennebert wrote:
> > I would need some help to understand how transcoders and
> > text handling within svg should work.
> >
> > o first, when I try to convert some svg that contains text
> > into pdf with Batik (1.6), text is always rendered as
> > strokes, even if it would be possible to render it with
> > pdf text primitives.
This was broken in the Batik 1.6 release. I am about to
incorporate the pdf-transcoder.jar from the 0.9alpha1 FOP
release into the Batik SVN repository.
> > o the strokeSVGText option seems to have disappeared in Fop
> > Trunk.
>
> At one point we thought this option would not be necessary. However, I
> think that we need to reintroduce it to provide a fallback
> if the special text handling does not produce satisfactory results. The
> idea behind the various TextElementBridges is that they determine
> themselves when they can paint text as text and when they have to resort
> to painting text as shapes. Thomas, what do you think about this topic?
Well I think that currently the text bridges do a pretty good job
determining if they are capable of drawing text as PDF text and drop
back to curves when needed. I would much rather work on catching cases
where this doesn't work properly than adding another option. Do you
know of cases right now where this doesn't work?
> > o only the PDFTranscoder is distributed with Batik. Is
> > the PSTranscoder broken? Should I adapt it to FOrayFont?
>
> It's not broken but has less features and I guess the demand hasn't been
> that high for pure SVG to EPS conversion. You should treat the
> EPSTranscoder and the PSTranscoder the same way as the PDFTranscoder.
> The PSTranscoder has less value than the EPSTranscoders. It was
> originally intended for use with SVG Print but I never got around to
> having a closer look at it. If anyone wanted PSTranscoder gone, I
> wouldn't be upset.
As far as I know no one has ever asked for EPS output from Batik.
Re: Text handling in svg files, transcoders
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Vincent
On 24.11.2005 21:00:58 Vincent Hennebert wrote:
> Hi,
>
> I would need some help to understand how transcoders and
> text handling within svg should work.
>
> o first, when I try to convert some svg that contains text
> into pdf with Batik (1.6), text is always rendered as
> strokes, even if it would be possible to render it with
> pdf text primitives. Whereas it is said on the Fop website
> [1] that normal PDF text is used when possible (I've tried
> with the text.svg file provided there). Is that normal?
For PDF, this should not be the case. I guess I need to check that again.
Prior to the 0.90alpha1 release this was fixed by introducing
PDFBridgeContext. For PostScript, this is the case, yes, because I
haven't had the time to do the necessary changes, yet.
> o the strokeSVGText option seems to have disappeared in Fop
> Trunk. It doesn't appear anywhere in the source code,
> except in a commented line in PSRenderer.java. Is it
> abandoned? Not yet implemented in Trunk?
At one point we thought this option would not be necessary. However, I
think that we need to reintroduce it to provide a fallback
if the special text handling does not produce satisfactory results. The
idea behind the various TextElementBridges is that they determine
themselves when they can paint text as text and when they have to resort
to painting text as shapes. Thomas, what do you think about this topic?
> o the PDFTranscoder.configure method is never called within
> Fop, neither by Batik. What is (was) its purpose?
It is used to configure the font subsystem through Avalon-style
configuration. I'm using it in my private code. This method will be
removed as the transcoders migrate out of FOP into Batik. However, I
assume we will reintroduce other mechanisms to configure fonts that make
it possible to make avalon-framework an optional dependency to the
transcoder code. BTW, this will have to count for the whole of the font
and PDF libraries. Batik doesn't want mandatory dependencies on too many
external libraries. On the other side, we haven't looked at the details,
yet. We may do a two-level approach, one of which will not make a
dependency on the font subsystem necessary. Don't get scared about that
right now. We'll figure out the details while we work on that stuff.
> o only the PDFTranscoder is distributed with Batik. Is
> the PSTranscoder broken? Should I adapt it to FOrayFont?
It's not broken but has less features and I guess the demand hasn't been
that high for pure SVG to EPS conversion. You should treat the
EPSTranscoder and the PSTranscoder the same way as the PDFTranscoder.
The PSTranscoder has less value than the EPSTranscoders. It was
originally intended for use with SVG Print but I never got around to
having a closer look at it. If anyone wanted PSTranscoder gone, I
wouldn't be upset.
Jeremias Maerki