PCL font spacing

[David Gerdt]

Hello all.

 

I'm using FOP to generate PCL on an AIX box. I'm running into some weird spacing surrounding several inline areas that I have. The attached PDFs (generated as PCL and then converted to PDFs--they accurately represent the actual printed copies) show the differences when the same fragment is rendered on my local Windows machine and on the AIX machine. I have tried trunk and 95beta on both systems with the same results. I knew that the font metrics would be slightly different between systems, but I don't understand the random spacing. Is this a JVM thing?

 

On AIX:

TDB2:/home/users/dgerdt:>java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM AIX build ca142-20060421 (SR5) (JIT enabled: jitc))

 

 

On Win:

C:\fop\fop-0.95beta>java -version
java version "1.4.2_17"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_17-b06)
Java HotSpot(TM) Client VM (build 1.4.2_17-b06, mixed mode)

 

The complete FO is below:

 

<?xml version="1.0" encoding="UTF-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:pcl="http://xmlgraphics.apache.org/fop/extensions/pcl">
 <fo:layout-master-set>
  <fo:simple-page-master margin-bottom="5mm" margin-top="12mm" margin-right="5mm" margin-left="10mm" page-height="11in" page-width="8.5in" master-name="family">
   <fo:region-body/>
  </fo:simple-page-master>
 </fo:layout-master-set>
 <fo:page-sequence force-page-count="no-force" initial-page-number="1" font-size="10pt" master-reference="family">
  <fo:flow flow-name="xsl-region-body">
   <fo:block margin-top="5mm">* Enter each student's name next to the test level used.</fo:block>
   <fo:block>* Mark the student's current <fo:inline text-decoration="underline">grade level</fo:inline> and how many months of that level were finished as of the testing date.</fo:block>
   <fo:block>* Complete and <fo:inline font-weight="bold" font-style="italic">sign</fo:inline> the VERIFICATION SECTION at the end of this form.</fo:block>
   <fo:block>* <fo:inline font-style="italic">You may copy these pages as needed, but please <fo:inline text-decoration="underline" font-weight="bold">do not</fo:inline> cut them apart!</fo:inline></fo:block>
  </fo:flow>
 </fo:page-sequence>
</fo:root>

 

Any help?

 

Thanks!

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Andreas Delmelle-2]

>----- Oorspronkelijk bericht -----
>Van: David Gerdt [mailto:Dgerdt@...]
>Verzonden: vrijdag, juni 13, 2008 04:43 PM
>

Hi
> I'm using FOP to generate PCL on an AIX box. I'm running into some
> weird spacing surrounding several inline areas that I have.
> The attached PDFs (generated as PCL and then converted to PDFs
> --they accurately represent the actual printed copies) show the
> differences when the same fragment is rendered on my local Windows
> machine and on the AIX machine. I have tried trunk and 95beta on both
> systems with the same results.
> I knew that the font metrics would be slightly different between systems,
> but I don't understand the random spacing. Is this a JVM thing?

I'm not sure I understand what's causing this issue either... Can you do us a favor and try replacing fo:inline with fo:wrapper, try again, and report back on whether this effect persists?

(Side-note: using fo:wrapper in cases where you don't really need an fo:inline, is much better for the memory footprint. In a large document containing lots of inlines, I once noticed a drop of +64MB in memory usage for the FO-tree. The reason is that the wrapper's properties are not stored as members of the corresponding Java object, which makes the instance size a lot smaller than that of blocks or inlines.)


TIA!

Andreas



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[David Gerdt]

I made the change to fo:wrapper and the problem does persist.

>>> "Andreas Delmelle" <andreas.delmelle@...> 6/13/2008 11:02 AM >>>

>----- Oorspronkelijk bericht -----
>Van: David Gerdt [mailto:Dgerdt@...]
>Verzonden: vrijdag, juni 13, 2008 04:43 PM
>

Hi
> I'm using FOP to generate PCL on an AIX box. I'm running into some
> weird spacing surrounding several inline areas that I have.
> The attached PDFs (generated as PCL and then converted to PDFs
> --they accurately represent the actual printed copies) show the
> differences when the same fragment is rendered on my local Windows
> machine and on the AIX machine. I have tried trunk and 95beta on both
> systems with the same results.
> I knew that the font metrics would be slightly different between systems,
> but I don't understand the random spacing. Is this a JVM thing?

I'm not sure I understand what's causing this issue either... Can you do us a favor and try replacing fo:inline with fo:wrapper, try again, and report back on whether this effect persists?

(Side-note: using fo:wrapper in cases where you don't really need an fo:inline, is much better for the memory footprint. In a large document containing lots of inlines, I once noticed a drop of +64MB in memory usage for the FO-tree. The reason is that the wrapper's properties are not stored as members of the corresponding Java object, which makes the instance size a lot smaller than that of blocks or inlines.)


TIA!

Andreas



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Andreas Delmelle-2]

>----- Oorspronkelijk bericht -----
>Van: David Gerdt [mailto:Dgerdt@...]
>Verzonden: vrijdag, juni 13, 2008 05:30 PM
>
>I made the change to fo:wrapper and the problem does persist.

OK, thanks for checking! (Even if it doesn't solve your problem, the advice is still valid: if possible, use fo:wrapper instead of fo:inline. Maybe we'd better add that hint to the website... I'll look into that.)

In the meantime, I've also been looking at the related code, and it indeed looks JVM-related. IIC, then the issue applies to all Java2D-based renderers. The most likely cause is that one (or more) of the Java AWT font-related classes return(s) different values for the same method call(s) on AIX and Windows. (PDF and PS would not exhibit this difference, since they don't rely on Java AWT for the font-metrics; using standard Java-APIs has its benefits, but clearly also its drawbacks...)

Is the JVM that is used on AIX the most recent available build for version 1.4.2 (if I read correctly, it's a build from 1.5-2 years ago)? If not, can you try upgrading to the latest build, and see if that helps?


Andreas



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[David Gerdt]

I ran the test again using the most recent build (ca142-20080515 (SR11)) with the same results. : (

 

Is there a way to circumvent this by setting up fonts manually?

>>> "Andreas Delmelle" <andreas.delmelle@...> 6/13/2008 12:12 PM >>>
>----- Oorspronkelijk bericht -----
>Van: David Gerdt [mailto:Dgerdt@...]
>Verzonden: vrijdag, juni 13, 2008 05:30 PM
>
>I made the change to fo:wrapper and the problem does persist.

OK, thanks for checking! (Even if it doesn't solve your problem, the advice is still valid: if possible, use fo:wrapper instead of fo:inline. Maybe we'd better add that hint to the website... I'll look into that.)

In the meantime, I've also been looking at the related code, and it indeed looks JVM-related. IIC, then the issue applies to all Java2D-based renderers. The most likely cause is that one (or more) of the Java AWT font-related classes return(s) different values for the same method call(s) on AIX and Windows. (PDF and PS would not exhibit this difference, since they don't rely on Java AWT for the font-metrics; using standard Java-APIs has its benefits, but clearly also its drawbacks...)

Is the JVM that is used on AIX the most recent available build for version 1.4.2 (if I read correctly, it's a build from 1.5-2 years ago)? If not, can you try upgrading to the latest build, and see if that helps?


Andreas



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jeremias Maerki-2]

No. The only option I see for you is that you generate PDF or PostScript
and convert it to PCL using GhostScript if you cannot use PostScript in
the first place. No chance that you can upgrade to a JDK 5 or 6? I can
see that IBM provides that for AIX:
http://www.ibm.com/developerworks/java/jdk/aix/service.html

On 16.06.2008 15:32:11 David Gerdt wrote:

> I ran the test again using the most recent build (ca142-20080515 (SR11)) with the same results. : (
>  
> Is there a way to circumvent this by setting up fonts manually?
>
> >>> "Andreas Delmelle" <andreas.delmelle@...> 6/13/2008 12:12 PM >>>
> >----- Oorspronkelijk bericht -----
> >Van: David Gerdt [mailto:Dgerdt@...]
> >Verzonden: vrijdag, juni 13, 2008 05:30 PM
> >
> >I made the change to fo:wrapper and the problem does persist.
>
> OK, thanks for checking! (Even if it doesn't solve your problem, the advice is still valid: if possible, use fo:wrapper instead of fo:inline. Maybe we'd better add that hint to the website... I'll look into that.)
>
> In the meantime, I've also been looking at the related code, and it indeed looks JVM-related. IIC, then the issue applies to all Java2D-based renderers. The most likely cause is that one (or more) of the Java AWT font-related classes return(s) different values for the same method call(s) on AIX and Windows. (PDF and PS would not exhibit this difference, since they don't rely on Java AWT for the font-metrics; using standard Java-APIs has its benefits, but clearly also its drawbacks...)
>
> Is the JVM that is used on AIX the most recent available build for version 1.4.2 (if I read correctly, it's a build from 1.5-2 years ago)? If not, can you try upgrading to the latest build, and see if that helps?
>
>
> Andreas
>
>

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[David Gerdt]

I just tried Java 6....same results. *sigh*

 

I'm pretty tied to rendering PCL directly without some intermediary process both due to speed concerns and the fact that I need to use the tray selection extension on this particular report.

 

Maybe I will just have to replace this section with an image....or is there any way to incorporate negative margins? Absolute positioning maybe? None of those sound particularly enjoyable, but....

 

 

>>> Jeremias Maerki <dev@...> 6/16/2008 11:24 AM >>>
No. The only option I see for you is that you generate PDF or PostScript
and convert it to PCL using GhostScript if you cannot use PostScript in
the first place. No chance that you can upgrade to a JDK 5 or 6? I can
see that IBM provides that for AIX:
http://www.ibm.com/developerworks/java/jdk/aix/service.html

On 16.06.2008 15:32:11 David Gerdt wrote:

> I ran the test again using the most recent build (ca142-20080515 (SR11)) with the same results. : (
> 
> Is there a way to circumvent this by setting up fonts manually?
>
> >>> "Andreas Delmelle" <andreas.delmelle@...> 6/13/2008 12:12 PM >>>
> >----- Oorspronkelijk bericht -----
> >Van: David Gerdt [mailto:Dgerdt@...]
> >Verzonden: vrijdag, juni 13, 2008 05:30 PM
> >
> >I made the change to fo:wrapper and the problem does persist.
>
> OK, thanks for checking! (Even if it doesn't solve your problem, the advice is still valid: if possible, use fo:wrapper instead of fo:inline. Maybe we'd better add that hint to the website... I'll look into that.)
>
> In the meantime, I've also been looking at the related code, and it indeed looks JVM-related. IIC, then the issue applies to all Java2D-based renderers. The most likely cause is that one (or more) of the Java AWT font-related classes return(s) different values for the same method call(s) on AIX and Windows. (PDF and PS would not exhibit this difference, since they don't rely on Java AWT for the font-metrics; using standard Java-APIs has its benefits, but clearly also its drawbacks...)
>
> Is the JVM that is used on AIX the most recent available build for version 1.4.2 (if I read correctly, it's a build from 1.5-2 years ago)? If not, can you try upgrading to the latest build, and see if that helps?
>
>
> Andreas
>
>

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jeremias Maerki-2]

Looking again at your FO: you don't specify a font, so you operate on
the default font. Have you tried using a different font? And have you
played with the "text-rendering" setting?
http://xmlgraphics.apache.org/fop/0.95/output.html#pcl-configuration
Just to see if anything changes.

I can't think of other work-arounds that can help you. Normally,
negative spaces are possible but I don't think we support spaces/margins on
the inline-level, yet.

On 16.06.2008 18:20:51 David Gerdt wrote:

> I just tried Java 6....same results. *sigh*
>  
> I'm pretty tied to rendering PCL directly without some intermediary
> process both due to speed concerns and the fact that I need to use the
> tray selection extension on this particular report.
>  
> Maybe I will just have to replace this section with an image....or is
> there any way to incorporate negative margins? Absolute positioning
> maybe? None of those sound particularly enjoyable, but....
>  
>  
>
> >>> Jeremias Maerki <dev@...> 6/16/2008 11:24 AM >>>
> No. The only option I see for you is that you generate PDF or PostScript
> and convert it to PCL using GhostScript if you cannot use PostScript in
> the first place. No chance that you can upgrade to a JDK 5 or 6? I can
> see that IBM provides that for AIX:
> http://www.ibm.com/developerworks/java/jdk/aix/service.html 
>
> On 16.06.2008 15:32:11 David Gerdt wrote:
> > I ran the test again using the most recent build (ca142-20080515 (SR11)) with the same results. : (
> >  
> > Is there a way to circumvent this by setting up fonts manually?
> >
> > >>> "Andreas Delmelle" <andreas.delmelle@...> 6/13/2008 12:12 PM >>>
> > >----- Oorspronkelijk bericht -----
> > >Van: David Gerdt [mailto:Dgerdt@...]
> > >Verzonden: vrijdag, juni 13, 2008 05:30 PM
> > >
> > >I made the change to fo:wrapper and the problem does persist.
> >
> > OK, thanks for checking! (Even if it doesn't solve your problem, the advice is still valid: if possible, use fo:wrapper instead of fo:inline. Maybe we'd better add that hint to the website... I'll look into that.)
> >
> > In the meantime, I've also been looking at the related code, and it indeed looks JVM-related. IIC, then the issue applies to all Java2D-based renderers. The most likely cause is that one (or more) of the Java AWT font-related classes return(s) different values for the same method call(s) on AIX and Windows. (PDF and PS would not exhibit this difference, since they don't rely on Java AWT for the font-metrics; using standard Java-APIs has its benefits, but clearly also its drawbacks...)
> >
> > Is the JVM that is used on AIX the most recent available build for version 1.4.2 (if I read correctly, it's a build from 1.5-2 years ago)? If not, can you try upgrading to the latest build, and see if that helps?
> >
> >
> > Andreas
> >
> >

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[David Gerdt]

When the problem first occurred, I tried a couple different fonts with the same results, which lead me to believe it was a Java problem. I eventually ran a test against every font available by default and the results were all over the board. Of the 35 fonts available to me, only two supported every variant I wanted to use (bold, italic, bold-italic, underline), and neither one of them were a suitable typeface for the document.

 

After running in circles for a while, I found that setting the JAVA_FONTS environment variable allowed me to pull new TTF files and use them. I was able to find a font that worked and am in good shape.

 

Should have caught on to this earlier, but thanks for the help/advice.

 

Dave

>>> Jeremias Maerki <dev@...> 6/16/2008 12:34 PM >>>
Looking again at your FO: you don't specify a font, so you operate on
the default font. Have you tried using a different font? And have you
played with the "text-rendering" setting?
http://xmlgraphics.apache.org/fop/0.95/output.html#pcl-configuration
Just to see if anything changes.

I can't think of other work-arounds that can help you. Normally,
negative spaces are possible but I don't think we support spaces/margins on
the inline-level, yet.

On 16.06.2008 18:20:51 David Gerdt wrote:

> I just tried Java 6....same results. *sigh*
> 
> I'm pretty tied to rendering PCL directly without some intermediary
> process both due to speed concerns and the fact that I need to use the
> tray selection extension on this particular report.
> 
> Maybe I will just have to replace this section with an image....or is
> there any way to incorporate negative margins? Absolute positioning
> maybe? None of those sound particularly enjoyable, but....
> 
> 
>
> >>> Jeremias Maerki <dev@...> 6/16/2008 11:24 AM >>>
> No. The only option I see for you is that you generate PDF or PostScript
> and convert it to PCL using GhostScript if you cannot use PostScript in
> the first place. No chance that you can upgrade to a JDK 5 or 6? I can
> see that IBM provides that for AIX:
> http://www.ibm.com/developerworks/java/jdk/aix/service.html
>
> On 16.06.2008 15:32:11 David Gerdt wrote:
> > I ran the test again using the most recent build (ca142-20080515 (SR11)) with the same results. : (
> > 
> > Is there a way to circumvent this by setting up fonts manually?
> >
> > >>> "Andreas Delmelle" <andreas.delmelle@...> 6/13/2008 12:12 PM >>>
> > >----- Oorspronkelijk bericht -----
> > >Van: David Gerdt [mailto:Dgerdt@...]
> > >Verzonden: vrijdag, juni 13, 2008 05:30 PM
> > >
> > >I made the change to fo:wrapper and the problem does persist.
> >
> > OK, thanks for checking! (Even if it doesn't solve your problem, the advice is still valid: if possible, use fo:wrapper instead of fo:inline. Maybe we'd better add that hint to the website... I'll look into that.)
> >
> > In the meantime, I've also been looking at the related code, and it indeed looks JVM-related. IIC, then the issue applies to all Java2D-based renderers. The most likely cause is that one (or more) of the Java AWT font-related classes return(s) different values for the same method call(s) on AIX and Windows. (PDF and PS would not exhibit this difference, since they don't rely on Java AWT for the font-metrics; using standard Java-APIs has its benefits, but clearly also its drawbacks...)
> >
> > Is the JVM that is used on AIX the most recent available build for version 1.4.2 (if I read correctly, it's a build from 1.5-2 years ago)? If not, can you try upgrading to the latest build, and see if that helps?
> >
> >
> > Andreas
> >
> >

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...