I'vm having serious difficulties generating a PDF from LxFree Java. In the past, I'd stumbled onto a workaround, but the gremlins seem to have reached it as well.
Method 1 - Using built-in export feature: File is generated, but on opening the viewer throws an error, "The font 'CenturyGothic' contains a bad /BBox". The resulting file contains no objects after the one which causes the error. error is reproducible with other fonts. I've had this problem since the first version I used last Spring. I've tried both the "more" and "less" compatible PDF exports.
Method 2 - Using 3rd-party PDF drivers (CutePDF, PaperPort Image Printer, and MS XPS Writer): View is set to actual size before printing. After setting the file destination, the driver process never seems to run (I watched in the task manager a couple times). In the past, I could get an output from PaperPort if I waited a while, but no luck today. As a test, I tried printing to a prn file from each driver, and in each case the resulting file was 0 kb.
Thoughts/suggestions/strategies for troubleshooting? I eventually printed from a png file, but the resolution left much to be desired.
Thanks!
PDF Printing - 1.1.8 and earlier
PDF export in LXFree for Java is through a relatively old and basic open source library. This has been update to work around some problems with exporting PDFs. You can e-mail a copy of the plot you are having difficulty with and we can see if it is possible to identify the problem and fix the library or find a workaround for getting a PDF to export.
The most likely problem is something to do with the fonts not being compatible with Adobe. There is a provision in PDF files for embedding a copy of fonts in the file. (The library that LXFree for Java uses does not support this) Not all fonts are compatible with PDF. That may be the reason that your other methods of generating a PDF are not working as well.
The most likely problem is something to do with the fonts not being compatible with Adobe. There is a provision in PDF files for embedding a copy of fonts in the file. (The library that LXFree for Java uses does not support this) Not all fonts are compatible with PDF. That may be the reason that your other methods of generating a PDF are not working as well.
Have you tried the More Compatible PDF Export option? This is found in the Format tab of the options window (View->Options). On Windows 7 this makes a difference in my being able to export a PDF that will open. With the more compatible PDF export option, I still get the notification that the font has a bad bounding box. But, the plot appears to export much more completely. The difference in the setting is how styled text is drawn when exporting a PDF.
Let me know if this helps. An alternative is to zoom larger before exporting an image file. (PDF export only works at actual size but image files can be zoomed) Depending on the size of the plot and available memory, this will produce a larger jpg or png file and gives a higher effective resolution.
Let me know if this helps. An alternative is to zoom larger before exporting an image file. (PDF export only works at actual size but image files can be zoomed) Depending on the size of the plot and available memory, this will produce a larger jpg or png file and gives a higher effective resolution.
I have tried with more compatible checked and unchecked. Since your last reply, I did a bit more tinkering to isolate the problem. First thing I noticed was that if I sent the Titleblock layer to the back, the PDF contained all of the lights, and 2/3 of the titleblock. That made me think there was a malformed object somewhere.
I added a big text object labeled 'CURSOR', then used an xml editor to move it around in the layer. Eventually I found that it would export if it was before a certain lxpath node, but not if it were after it. I deleted that path, and the remainder of the drawing showed up in the PDF export. I still get the bad bbox error, but it displays correctly.
Inspecting the bad path node, it has two 'e' nodes; in each of those nodes, the 'x' element has a value of 'NaN' instead of a coordinate value. Is that ever a valid value?
I'll email you files with the troubleshooting results.
I added a big text object labeled 'CURSOR', then used an xml editor to move it around in the layer. Eventually I found that it would export if it was before a certain lxpath node, but not if it were after it. I deleted that path, and the remainder of the drawing showed up in the PDF export. I still get the bad bbox error, but it displays correctly.
Inspecting the bad path node, it has two 'e' nodes; in each of those nodes, the 'x' element has a value of 'NaN' instead of a coordinate value. Is that ever a valid value?
I'll email you files with the troubleshooting results.
It appears that Acrobat stops rendering a PDF when it encounters certain errors. This is not true if you view the PDF with Preview on a Mac which seems to just ignore the errors. (I would speculate that Acrobat stops rendering as a defense against malicious PDFs intended to inject malware on Windows. But, that is just a guess.)
The preference option "More Compatible PDF Export" changes the way that styled text fields are exported. Without this option, Acrobat will often stop rendering the exported PDF when it gets to a styled text field. This has to do with how the gnujpdf library converts the styled text to PDF output. At this tie it does not appear possible to fix that library. With the option enabled, the styled text is drawn differently when exporting to PDF. This may result in loss of formatting or styles but it also does not cause the PDF to be partly rendered by Acrobat.
This is probably what you noticed with your CURSOR text field experiment. I'm going to guess that this was a styled rather than plain text field and that PDF export would succeed if the "More Compatible PDF Export" was set.
Can you tell if the PathShape that cause your problem was part of the key or title block? Nan stands for "Not a Number" and is typically generated by division by zero. Since the PathShape was automatically generated, it would help to know if it was the title block or key block that did this so I can look for a possible division by zero and trap it.
The preference option "More Compatible PDF Export" changes the way that styled text fields are exported. Without this option, Acrobat will often stop rendering the exported PDF when it gets to a styled text field. This has to do with how the gnujpdf library converts the styled text to PDF output. At this tie it does not appear possible to fix that library. With the option enabled, the styled text is drawn differently when exporting to PDF. This may result in loss of formatting or styles but it also does not cause the PDF to be partly rendered by Acrobat.
This is probably what you noticed with your CURSOR text field experiment. I'm going to guess that this was a styled rather than plain text field and that PDF export would succeed if the "More Compatible PDF Export" was set.
Can you tell if the PathShape that cause your problem was part of the key or title block? Nan stands for "Not a Number" and is typically generated by division by zero. Since the PathShape was automatically generated, it would help to know if it was the title block or key block that did this so I can look for a possible division by zero and trap it.
I think I misunderstood some things.
First, your CURSOR text field is a plain text field and it was not causing the problem, you used it to find the problem. I get that now after looking at the insides of the file.
Second, the PathShape that caused the problem was not part of an automatically generated Title Block, it is on your layer called "Title Block".
So, there are a lot of PathShapes on that layer. You can't draw a path shape. So, they must have been created by the Convert To Path command. That by itself should not have caused a point with a NaN coordinate. Can you recall what else you might have done to those path shapes? I'd guess some sort of resizing might have caused the division by zero. But any hints you can think of would help.
First, your CURSOR text field is a plain text field and it was not causing the problem, you used it to find the problem. I get that now after looking at the insides of the file.
Second, the PathShape that caused the problem was not part of an automatically generated Title Block, it is on your layer called "Title Block".
So, there are a lot of PathShapes on that layer. You can't draw a path shape. So, they must have been created by the Convert To Path command. That by itself should not have caused a point with a NaN coordinate. Can you recall what else you might have done to those path shapes? I'd guess some sort of resizing might have caused the division by zero. But any hints you can think of would help.
The paths in my titleblock were originally created by converting my old autocad titleblock to DXF, importing it into a blank LxFree doc, fixing colors and lineweights, and then copy/pasting those objects into a plot file. I didn't have any problems on the first couple go-rounds with the titleblock.
On the current plot, there was definitely some re-sizing to fit the correct page size. I think I grouped most of the objects before re-sizing. Perhaps somewhere in that process a divide by zero got introduced when it the program applied the re-size to the objects within the group?
On the current plot, there was definitely some re-sizing to fit the correct page size. I think I grouped most of the objects before re-sizing. Perhaps somewhere in that process a divide by zero got introduced when it the program applied the re-size to the objects within the group?
There's a new build of #LXFreeForJava available for download. This build contains the first public beta of the new Pro Features that can be enabled for testing.
This version also will trap and correct objects that have NaN coordinates. It also prevents these from being created by resizing in the first place. There's also a new option under "More compatible PDF export" that gives you the choice to pre-render styled text objects when exporting PDFs.
This version also will trap and correct objects that have NaN coordinates. It also prevents these from being created by resizing in the first place. There's also a new option under "More compatible PDF export" that gives you the choice to pre-render styled text objects when exporting PDFs.