PDF print errors with SVG text

[Ken Green <ke...@comcast.net>]

Hello,

I am working on PDF report generation that includes SVG-driven graphs. After reading
up on old posts, I found the solution to the text-rendering issues that can come up
with SVG text (that is, disable the text stroking in the userconfig.xml file). So, all
looked great when I viewed my document on screen, but, when I went to print it,
as soon as I got to a page that contained SVG text, the print job stopped and I got
a page with the following error on it:


ERROR: nocurrentpoint
OFFENDING COMMAND: currentpoint

STACK:

-dictionary-
-savelevel-
-savelevel-
-savelevel-


Any suggestions ? Printing works fine when I use the default SVG text handling,
and it admittedly looks good on paper, but the resulting file size is much larger,
the processing takes much longer, and the on-screen display is pretty rough; so,
I'd like to stick with the other method.

Thanks !

Ken

Re: PDF print errors with SVG text

[Keiron Liddle <ke...@aftexsw.com>]

On Thu, 2002-07-18 at 02:18, Ken Green wrote:
> Hello,
> 
> I am working on PDF report generation that includes SVG-driven graphs. After reading
> up on old posts, I found the solution to the text-rendering issues that can come up
> with SVG text (that is, disable the text stroking in the userconfig.xml file). So, all
> looked great when I viewed my document on screen, but, when I went to print it,
> as soon as I got to a page that contained SVG text, the print job stopped and I got
> a page with the following error on it:
> 
> 
> ERROR: nocurrentpoint
> OFFENDING COMMAND: currentpoint
> 
> STACK:
> 
> -dictionary-
> -savelevel-
> -savelevel-
> -savelevel-
> 

This looks like some sort of postscript error which doesn't really tell
me what the problem is with the pdf (or even some other error).
Is it possible to break it down to the smallest fo+svg file that
reproduces the error. Then you could test that, convert to postscript,
try with Ghostscript etc.

It is probably some command inside the text section that should be
outside (or vice versa).
The problem would be in the drawString method inside the PDFGraphics2D.

> Any suggestions ? Printing works fine when I use the default SVG text handling,
> and it admittedly looks good on paper, but the resulting file size is much larger,
> the processing takes much longer, and the on-screen display is pretty rough; so,
> I'd like to stick with the other method.
> 
> Thanks !
> 
> Ken