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 Thorsten Daum <th...@stny.rr.com> on 2002/02/20 05:35:35 UTC
SVG-rendered text looks crude with FOP 0.20.3rc; looked fine with 0.15.0
Hi,
SVG-rendered text looks very crude using FOP 0.20.3.rc (with Cocoon 2.0.1 on
Tomcat 3.3a/4.0.2, JDK 1.3, SuSE 7.3). I get the same undesired effect using
FOP 0.20.1 stand-alone.
Basically, I am using sth like this,
<svg:text x="365pt" y="45pt"
style="font-size:14;fill:#10559B;stroke:#10559B;stroke-width:0">
I might, in addition, add 'font-family:Helvetica' to the style attribute.
I suspect the problem might be related to the SVG text being rendered as a
set of curves as opposed to straight PDF text.
The funny thing is that this works fine using FOP 0.15.0 with Cocoon 1.8.2 on
Tomcat 3.2.3 (which all were part of the stock SuSE 7.3 distribution, BTW.)
I can't use the older version because it doesn't seem to support
superscripted text, which I need for the inclusion of service marks, e.g.,
<fo:inline font-size="8pt" vertical-align="super">SM</fo:inline>
Any help would be greatly appreciated. This is the one stumbling block to a
successful deployment. So far, the guys in management have been happy as
clams to replace a commercial, proprietary solution with FOP.
Thanks,
Thorsten
Re: SVG-rendered text looks crude with FOP 0.20.3rc; looked fine with 0.15.0
Posted by Jeremias Maerki <je...@outline.ch>.
> 1. How do I configure this when using FOP with Cocoon2? After all, FOP just
> comes as a JAR file with Cocoon. I did unjar fop-0.20.3rc.jar, added the
> 'strokeSVG' entry to conf/userconfig.xml and re-jarred it. However, the
> change does not take effect. It seems I have to implicitely tell FOP to use
> userrconfig.xml. How do I do that when FOP is invoked by Cocoon?
>
> (Is this perhaps more of a question for the cocoon-users list?)
This may help you (we had that a few days ago):
http://marc.theaimsgroup.com/?l=fop-dev&m=101379793919354&w=2
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
Volunteer for code integration? Re: User config
Posted by "Peter B. West" <pb...@powerup.com.au>.
As there have been no objections, I'll press ahead with this. From
those who have expressed interest in getting involved, is there anyone
who would like to start by integrating my Options.java into the
maintenance branch and trunk. The changes are fairly extensive.
Peter
Peter B. West wrote:
> I think that the reading of the userconfig file should be an option in
> the system config file. The example userconfig is a null file
> (everything is commented out), so the system config file could be
> changed to refer to it without doing any damage, unless the user
> changes the distributed user config and does *not* want it read. From
> memory, the current code searches for the userconfig file in
> user-relative places. If this is changed to search firstly in
> user-relative, then in system-relative places, it would give the user
> the option to change the distributed user config file in place, or to
> copy it to user space and modify it there. This is what I've
> implemented in my own code, and it certainly makes my testing a lot
> easier. In that code, a command line option specifying a user config
> will override the specification in the system config. The other thing
> that would probably be useful in that situation is a command line
> switch to turn off user config altogether.
>
> Peter
>
> Thorsten Daum wrote:
>
>> Hi,
>>
> ...
>
>>
>> Thanks, I had seen that, but I had missed that I had to implicitely
>> include the config file when using FOP stand-alone, e.g., ./fop.sh -c
>> conf/userconfig.xml, so originally I didn't pursue this avenue further.
>>
>>
>> 1. How do I configure this when using FOP with Cocoon2? After all,
>> FOP just comes as a JAR file with Cocoon. I did unjar
>> fop-0.20.3rc.jar, added the 'strokeSVG' entry to conf/userconfig.xml
>> and re-jarred it. However, the change does not take effect. It seems
>> I have to implicitely tell FOP to use userrconfig.xml. How do I do
>> that when FOP is invoked by Cocoon?
>>
>
>
User config
Posted by "Peter B. West" <pb...@powerup.com.au>.
I think that the reading of the userconfig file should be an option in
the system config file. The example userconfig is a null file
(everything is commented out), so the system config file could be
changed to refer to it without doing any damage, unless the user changes
the distributed user config and does *not* want it read. From memory,
the current code searches for the userconfig file in user-relative
places. If this is changed to search firstly in user-relative, then in
system-relative places, it would give the user the option to change the
distributed user config file in place, or to copy it to user space and
modify it there. This is what I've implemented in my own code, and it
certainly makes my testing a lot easier. In that code, a command line
option specifying a user config will override the specification in the
system config. The other thing that would probably be useful in that
situation is a command line switch to turn off user config altogether.
Peter
Thorsten Daum wrote:
>Hi,
>
...
>
>Thanks, I had seen that, but I had missed that I had to implicitely include
>the config file when using FOP stand-alone, e.g.,
>./fop.sh -c conf/userconfig.xml, so originally I didn't pursue this avenue
>further.
>
>
>1. How do I configure this when using FOP with Cocoon2? After all, FOP just
>comes as a JAR file with Cocoon. I did unjar fop-0.20.3rc.jar, added the
>'strokeSVG' entry to conf/userconfig.xml and re-jarred it. However, the
>change does not take effect. It seems I have to implicitely tell FOP to use
>userrconfig.xml. How do I do that when FOP is invoked by Cocoon?
>
Re: SVG-rendered text looks crude with FOP 0.20.3rc; looked fine with 0.15.0
Posted by Thorsten Daum <th...@stny.rr.com>.
Hi,
On Wednesday 20 February 2002 03:44, Keiron Liddle <ke...@aftexsw.com>
wrote:
> Of course the first place you should look is the documentation:
> http://xml.apache.org/fop/svg.html
[which says, include
<entry>
<key>strokeSVGText</key>
<value>false</value>
</entry>
in FOP's user config]
Thanks, I had seen that, but I had missed that I had to implicitely include
the config file when using FOP stand-alone, e.g.,
./fop.sh -c conf/userconfig.xml, so originally I didn't pursue this avenue
further.
Now I get nice looking fonts (and smaller PDF files), but unfortunately, two
problems remain.
1. How do I configure this when using FOP with Cocoon2? After all, FOP just
comes as a JAR file with Cocoon. I did unjar fop-0.20.3rc.jar, added the
'strokeSVG' entry to conf/userconfig.xml and re-jarred it. However, the
change does not take effect. It seems I have to implicitely tell FOP to use
userrconfig.xml. How do I do that when FOP is invoked by Cocoon?
(Is this perhaps more of a question for the cocoon-users list?)
2. In FOP 0.15.0, I was able to use sth like style="stroke-width:1" to change
the "boldness" of a string. However, FOP 0.23.3rc (w/Batik) seems to ignore
stroke-width. What attribute should I use now? "font-weight:bold" doesn't do
what I want; it does render bold text, but also apparently changes the font
from Helvetica to Times Roman. (Adding "font-family:Helvetica" doesn't help.)
Again, any pointers will be greatly appreciated.
Thanks,
Thorsten
> Note: FOP 0.15 did not use batik, which is why it is limited
>
> On 2002.02.20 05:35 Thorsten Daum wrote:
> > Hi,
> >
> > SVG-rendered text looks very crude using FOP 0.20.3.rc (with Cocoon 2.0.1
> > on
> > Tomcat 3.3a/4.0.2, JDK 1.3, SuSE 7.3). I get the same undesired effect
> > using
> > FOP 0.20.1 stand-alone.
> >
> > Basically, I am using sth like this,
> >
> > <svg:text x="365pt" y="45pt"
> > style="font-size:14;fill:#10559B;stroke:#10559B;stroke-width:0">
> >
> > I might, in addition, add 'font-family:Helvetica' to the style attribute.
> >
> > I suspect the problem might be related to the SVG text being rendered as
> > a
> > set of curves as opposed to straight PDF text.
> >
> > The funny thing is that this works fine using FOP 0.15.0 with Cocoon
> > 1.8.2 on
> > Tomcat 3.2.3 (which all were part of the stock SuSE 7.3 distribution,
> > BTW.)
> > I can't use the older version because it doesn't seem to support
> > superscripted text, which I need for the inclusion of service marks,
> > e.g.,
> >
> > <fo:inline font-size="8pt" vertical-align="super">SM</fo:inline>
> >
> > Any help would be greatly appreciated. This is the one stumbling block to
> > a
> > successful deployment. So far, the guys in management have been happy as
> > clams to replace a commercial, proprietary solution with FOP.
> >
> > Thanks,
> > Thorsten
Re: SVG-rendered text looks crude with FOP 0.20.3rc; looked fine with 0.15.0
Posted by Keiron Liddle <ke...@aftexsw.com>.
Hi,
Of course the first place you should look is the documentation:
http://xml.apache.org/fop/svg.html
This should answer all your questions.
Note: FOP 0.15 did not use batik, which is why it is limited
On 2002.02.20 05:35 Thorsten Daum wrote:
> Hi,
>
> SVG-rendered text looks very crude using FOP 0.20.3.rc (with Cocoon 2.0.1
> on
> Tomcat 3.3a/4.0.2, JDK 1.3, SuSE 7.3). I get the same undesired effect
> using
> FOP 0.20.1 stand-alone.
>
> Basically, I am using sth like this,
>
> <svg:text x="365pt" y="45pt"
> style="font-size:14;fill:#10559B;stroke:#10559B;stroke-width:0">
>
> I might, in addition, add 'font-family:Helvetica' to the style attribute.
>
> I suspect the problem might be related to the SVG text being rendered as
> a
> set of curves as opposed to straight PDF text.
>
> The funny thing is that this works fine using FOP 0.15.0 with Cocoon
> 1.8.2 on
> Tomcat 3.2.3 (which all were part of the stock SuSE 7.3 distribution,
> BTW.)
> I can't use the older version because it doesn't seem to support
> superscripted text, which I need for the inclusion of service marks,
> e.g.,
>
> <fo:inline font-size="8pt" vertical-align="super">SM</fo:inline>
>
> Any help would be greatly appreciated. This is the one stumbling block to
> a
> successful deployment. So far, the guys in management have been happy as
> clams to replace a commercial, proprietary solution with FOP.
>
> Thanks,
> Thorsten
>