PDFGraphics2D, SVGGraphics2D and fonts: Suggestions for new class methods
The current way that fonts are handled is hobbled by the fact that the Graphics2D is the class that PDFGraphics2D and SVGGraphics2D inherit from. One problem is that java.awt.Font can only instantiate fonts that the JVM knows about. What is needed is a call to tell both PDFGraphics2D and SVGGraphics2D which fonts to map each java.awt.Font to. There are a few problems that need to be solved: 1) When generating to PDF one needs a way to tell it to map TrueType fonts to metrically equivalent Type 1 fonts. ie when it sees a particlar java.awt.Font instance it should use Type 1 font XYZ in the output. Rather than the F1, F2,. etc sort of nomenclature that is used in FontSetup/FontInfo instead the mapping should be between particular java.awt.Font instances and some textually described font (eg Helvetica or something similar). This has to be callable to be set up in advance before some graphics library that only knows Graphics2D calls would be called. 2) When generating to a format that supports font lists (eg in CSS where if font a isn't available then try fonts b and then c) one needs a way to specify to generate a list of fonts in the output format. The problem is that the Graphics2D setFont only allows a single font to be currently specified. Well, I want to be able to call some other method and tell SVGGraphics2D (or whatever similar class that generates to other formats) in advance that when it sees a set to a particular java.awt.Font then it should look-up and find a list of fonts that will serve in its place in the target document that is being generated. The interface here would be the same as for what is described in the first problem above but there would be a list of fonts rather than a single font in the text that the java.awt.Font object got mapped to. 3) Some of the font family names that Java uses are unwise for general web page and CSS use. For example, on my machine running NT4 SP6a if I instantiate a font of type sansserif and style Font.ITALIC then the font- family name that Java assigns to it is sansserif.italic. If one tries to instantiate a font of type sansserif.italic and give it style Font.ITALIC Java will literally default it to Arial because Java says that the font family sansserif.italic does not have an italic style. The sansserif.italic font family has its italic style assigned to PLAIN! As a result Batik will generate a style in a font-face tag that looks like: style=font-family:sansserif.italic; font-style:italic; font-weight:normal; Its dumb to put styles in as part of the font family name. Downstream at some point some display device is going to say that it doesn't even have a font family of sansserif.italic and will default to some other font. Batik or FOP ought to provide a way for programmers to prevent this sort of nonsense from mucking things up at some later stage of processing. Font family names that get put into generated output files ought not to be made into some overly specific name just because Sun or Microsoft (not sure who to blame for this) defined a font family in this fashion. That information belongs with font-style. Its far more easy to start with sansserif and the italic as separate properties and look for a font family that puts italic in as part of its name than it is to go in the opposite direction. Doing it always in one direction for look-ups makes it easier and more consistent. Imagine one popped down a combo box on some interface, listed all font families, the user chose sansserif.italic, and then the user chose the italic property, and then the result was that the display software found that that font family used a totally different font. My point in mentioning SVGGraphics2D in this message is that PDFGraphics2D and SVGGraphics2D should receive the same enhancement in terms of what the added methods should look like. I even think that they should inherit from a base class that gets these methods (and perhaps supporting other classes to hold the data that gets passed to them) defined for them. Bottom line: We ought to define some common methods in PDFGraphics2D and SVGGraphics2D that will allow a programmer to use the same calls in Batik and FOP to handle fonts more intelligently. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Ideas about PDFGraphics2D font handling for True Type to Type 1
On Mon, 20 Aug 2001 10:31:35 +0200 (CEST), Tore Engvig wrote: I'm not sure that you always can assume that java fonts are the same as your system fonts, and I don't think you should map Arial to Helvetica. If I remember correctly, Helvetica is a nice font, but Arial looks more like... ugly. I am not generating visible documents with Arial. I'm generating PDF. So what Arial looks like does not matter as long as it has the same font metrics as Helvetica. Also Arial exists in dozens of different versions, that goes for other fonts to. But the problem is that I need a TrueType font that I can instantiate. I can't instantiate a font that doesn't exist. Then I can call PDFDocumentGraphics2D.setFont(Font) with it. Windows machines have TrueType fonts. They rarely have Type 1 fonts. I want to use these ubiquitous fonts since I can count on being able to instantiate them. I guess that the simplest solution to your problem is to create fontmetrics for your java fonts (those found in jre/lib) and add those to fop with the same name as their java name. How does that help? I want to specify the 3 font families that are built into Acrobat Reader (Helvetica, Times Roman, Courier). But in order to do that one has to be able to call PDFDocumentGraphics2D (or PDFGraphics2D) with setFont calls to specify them. Well, those are Type 1 fonts. I don't believe that Java can load Type 1 fonts from jre\lib\fonts on Win32 and it probably can't load Type 1 fonts from jre/lib/fonts on Linux or Unix either. But it can load TT fonts from jre/lib/fonts. Some TT fonts have the same font metrics as those 3 Type 1 fonts. So, since I need a way to tell the PDF document generation classes to use fonts that match those Type 1 font metrics the TrueType fonts that are roughly equivalent to them and which have the same font metrics seem like the ones to use. You don't have to embed them in your document (just don't use embed file in your userconfig.xml). I am not creating a document using XSL FO. I'm calling the PDFDocumentGraphics2D. (I'm going to be using XSL FO eventually though I don't see that that affects the problem anyhow) As for sansserif and sans-serif, I don't think it's controversial to add a mapping for both sansserif and sans-serif in FontSetup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Ideas about PDFGraphics2D font handling for True Type to Type 1
Here's the problem in a nutshell: Java's Font class knows about the True Type fonts that it loaded from jre\lib \fonts and it also seems to know about TrueType fonts that are in the operating system's directory of fonts (on my NT4 box they are in winnt\fonts). But those font names are not going match the Type 1 font names that FOP's FontInfo.java and FontSetup.java know about. It appears that FontSetup.java does provide a mechanism for mapping TT fonts to Type 1 PDF core fonts. What I'm arguing here is that more calls to FontInfo.addFontProperties need to be added to FontSetup in order to support mapping of more TT fonts to Type 1 fonts. Elsewhere I've been told that the TrueType fonts Courier New and Times New Roman are supposed to have the same font metrics as the Type 1 fonts Courier and Times Roman. This same person also claimed that Arial has the same font metrics as Helvetica. If this is really true (anyone know a good way to find out?) then it makes sense to me for FontInfo to map those TrueType fonts to their corresponding Type 1 metric equivalalents. So True Type fonts available in Java should be mapped to Type 1 fonts in PDF as follows: Arial -- Helvetica Times New Roman -- Times-Roman Courier New-- Courier and when they have bold and italic they should be mapped appropriately as well. I came across this relevant quote in an article by Thomas Phinney about TrueType and PostScript Type 1. Article excerpts: According to Dov Isaacs,then Adobe 's Manager of Quality Assurance,Printing Systems Division, regardless of whether you are on a Mac or a PC run- ning Windows ...or above,you can mix TrueType and Type .with the caveat that you should never have both TrueType and Type .fonts with the same exact names on the same system.Indeed,having any two fonts with identical menu names or PostScript font names can confuse the operating system or your applications,with unpredictable results. ... When dealing with fonts on the computer 's side, one needs to be careful about deliberately substitut- ing Arial for Helvetica and Times New Roman for Times,or vice versa.Although the basic spacing of the substituted fonts is identical,their kerning pairs are not.is can cause text to reflow if one switches between two different-but-almost-the-same fonts on the computer doing the typesetting,if the program supports kerning pairs (graphics and DTP programs, and some better word processors).In situations in which exact line breaks are not critical,or applica- tions in question do not use kerning,problems are unlikely. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Test Case FOP and Java don't recognize and name fonts in compatible ways
The core fonts for PDF do not have names that match with the names that Java uses for what are really the same fonts and font families. So if one tries to initialize fonts using names that are from the PDF font list as implemented in org.apache.fop.render.pdf.FontSetup the Java run-time doesn't recognize the names and maps them to a different default font family instead. But that font family is not one that is in FontSetup.java. In the case of sansserif its pretty simple: Java uses sansserif whereas FontSetup uses sans-serif. There is code that maps sanserif to sans-serif but sanserif is not spelled the same as sansserif. (I've pointed this out a week or two ago in a previous message btw) However, sansserif is not the only font that has this problem. See the initFonts() method in the attached TestCase1.java. One other problem is that Java concatenates the style onto the base name to create the name and the family name. This further ensures that FontInfo.java will fail to get a match when it does font look-ups. This seems like a dumb thing for the Java run-time to do since font-style is supposed to be used for that purpose in CSS. I think FontInfo.java and FontSetup.java have to be smarter to map the font families and names that Java's run-time recognizes to font families and font names that are PDF-compatible. I've attached a newer version of my TestCase1.java test case program. This one instantiations a variety of fonts and then does System.out.printlns that show what Java thinks they are. It also shows error messages that org.apache.fop.layout.FontInfo.java generates because does not recognize many of these fonts. TestCase1.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Test case for PDFDocumentGraphics2D rotated text problem
On Wed, 15 Aug 2001 09:20:00 +0200, Keiron Liddle wrote: Thanks for the test. I'm really not sure how to fix this. I can make it so that the text is almost in the right position except it is flipped on the horizontal axis (so you'll have to stand on your head to read it:) Keiron, In my real app the text messages that are running vertically (ie the ones that are at 12 o'clock and 6 o'clock) actually get drawn at 3 o'clock and 9 o'clock. The idea is to put labels on either side of a pie chart or other type of chart. I think the solution is a bit ugly due to the different coordinate systems. I need to apply the transform in order to tell the Graphics2D object to draw the text running vertically. THe font problem is either a problem with FOPs font setup (possibly a version thing) or something to do with the acrobat viewer. It has no problem with Acrobat 5. So then Acrobat can draw the text at 45, 135, 225 and 315 degrees? (ie 1:30, 4:30, 7:30, 10:30) I don't see any text at those positions in the textAsShapes=false version. I will try a later version of FOP and Batik. I'll get the latest stuff from CVS and try it again today. Also, I have Acrobat 4.05 coming as an update but Adobe says it will take 4-6 weeks to get it. I guess I could go get the Acrobat Reader plug-in for v5 and try that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Test case for PDFDocumentGraphics2D rotated text problem
This is a test case to demonstrate problems with how PDFDocumentGraphics2D renders text that is rotated. The text at 90 and 270 degrees is flipped around in pdfasshapes.pdf as compared to how it is in svgtest.svg and pdfnotshapes.pdf. Also, the text at the angles that start at 45 degrees and then increment at 90 degree intervals does not show up in the pdfnotshapes.pdf and Acrobat complains when it loads the file about not finding a font. The font can be changed in the initFonts() method. See the attached file TestCase1.java. It generates an SVG and two PDF files from the same set of calls to the Graphics2D APIs. I am running FOP and Batik as downloaded last Wednesday Aug 8 2001. I'm also using Jaxp 1.1.1, Crimson 1.1.1, and Xalan 2.2.D8. Also, building and running on JBuilder 5 Pro. Viewing SVG with the Batik SVG Browser and viewing PDF with full Acrobat 4.0. BTW, Acrobat holds a lock on a file it is showing. So you have to close the file in Acrobat to write out a new version of the PDF. The SVG Browser doesn't hold a lock on the file and it has a handy button to click to reload it. The paths to which the output get written are embedded in the file. Edit these lines to change them: String SvgOutputFileName = new String(\\tmp\\svgtest.svg); String PdfTextAsShapesFileName = new String(\\tmp\\pdfasshapes.pdf); String PdfTextNotShapesFileName = new String(\\tmp\\pdfnotshapes.pdf); If anyone wants the 3 output files I can send them. I didn't want to clog up the list with too many attachments. TestCase1.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Why some fonts in FontSetup but not others?
Keiron, If one took the SVG document and parsed it into a DOM tree could one then look at that tree to find out which fonts it used, add an XSL FO set of tags around it that called out which fonts to embed and then convert that into a PDF? BTW, I've posted in a couple of forums elsewhere asking for info about which fonts are available in each version of Acrobat and Acrobat Reader. I'll let you know if I learn anything. On Mon, 13 Aug 2001 10:25:01 +0200, Keiron Liddle wrote: So in particular for the PDFGraphics2D you have two options: - use shapes to draw text (makes the file much larger and looks bad in the viewer but prints ok) - embedd the font using FOP embedding font technique, currently this is not implemented for svg text - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Questions about FOP, Batik, Java Graphics to PDF, SVG, etc
I'm intending to try to use Batik and FOP to convert graphics drawn with java.awt.Graphics2D to PDF, SVG, and PNG. I'm especially interested in generating PDF. The relevant classes appear to be: org.apache.fop.svg.PDFDocumentGraphics2D org.apache.fop.svg.PDFGraphics2D org.apache.fop.svg.PDFTranscoder org.apache.fop.svg.PDFDocument org.apache.batik.svggen.SVGGraphics2D Questions: 1) I've seen these paths used in discussions on this list. But they are not in the source downloads. Are they old package paths for old versions that are no longer used? org.apache.svg.PDFDocumentGraphics2D org.apache.svg.PDFTranscoder 2) Should I be trying to use the release versions of Batik and FOP? Or nightlies? Its my impression from reading the lists that important fixes have been getting done in this area. I don't need my app to be stable enough for production as I'm still developing myself. So it makes more sense to me to be on the bleeding edge reporting and even debugging what happens in the latest versions of the relevant FOP and Batik classes so that they work as well as possible in their future versions. So does it make sense to go with the recent FOP nightlies? Kinda seems that way to me. 3) Can one use the recent nightlies of Batik with the recent nightlies of FOP? Or does Batik need to be customized to be workable with FOP? 4) What's the longer term plan with Batik and FOP integration? Will some of the code for doing these things be shifted btw FOP and Batik? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
