Re: svn commit: r677648 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java
Adrian, for the same reason I must disagree with the this change: If the fonts are not available (symbol, zapf dingbats), fop will just fall back to the default font, where the character is also not available. What you loose in this case is a little bit of performance. What you gain is the chance that fop is finally able to produce special characters (which has been a missing feature for a long time). So rather than shorting this list, you could enlengthen it with the symbol fonts available in afp. Max Andreas Delmelle schrieb: On Jul 17, 2008, at 19:39, [EMAIL PROTECTED] wrote: Hi Adrian, Author: acumiskey Date: Thu Jul 17 10:39:14 2008 New Revision: 677648 URL: http://svn.apache.org/viewvc?rev=677648view=rev Log: ZapfDingbats and Symbol is not always available on the AFPRenderer so we can't have these as default font family properties unfortunately. I understand... I still think it's a nice showcase for character-by-character font-selection added by Max, so I'm wondering, if the AFPRenderer is the only exception, we should be looking at a way to fall back with a warning, rather than disabling the feature for all other output formats as well (?) Just my 2 cents. Andreas signature.asc Description: OpenPGP digital signature
Re: svn commit: r677648 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java
Hi Max, The problem with AFP is that there is no concept of a default set of base fonts. You have to purchase your fonts as a pack from IBM and I'm not too sure about the availability of Symbol and Zapfdingbats - they seem have their own way of doing things :). FOP does however provide a default base font configuration for AFP of sans-serif, serif and monospace - but there are no guarantees as to their availability on any given installation. The branch I am working (http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_AFPGOCAResources) also contains a populated fop.xconf which provides commonly used raster font configurations for Times Roman, Helvetica and Courier. Adrian. Max Berger wrote: Adrian, for the same reason I must disagree with the this change: If the fonts are not available (symbol, zapf dingbats), fop will just fall back to the default font, where the character is also not available. What you loose in this case is a little bit of performance. What you gain is the chance that fop is finally able to produce special characters (which has been a missing feature for a long time). So rather than shorting this list, you could enlengthen it with the symbol fonts available in afp. Max Andreas Delmelle schrieb: On Jul 17, 2008, at 19:39, [EMAIL PROTECTED] wrote: Hi Adrian, Author: acumiskey Date: Thu Jul 17 10:39:14 2008 New Revision: 677648 URL: http://svn.apache.org/viewvc?rev=677648view=rev Log: ZapfDingbats and Symbol is not always available on the AFPRenderer so we can't have these as default font family properties unfortunately. I understand... I still think it's a nice showcase for character-by-character font-selection added by Max, so I'm wondering, if the AFPRenderer is the only exception, we should be looking at a way to fall back with a warning, rather than disabling the feature for all other output formats as well (?) Just my 2 cents. Andreas
Re: Print JPEG HeadlessException - Please Help
Looks like this is set for sure. I even tried running with Java 1.5. I think I might be beyond help, time to look for a new trade. Andreas Delmelle-2 wrote: - Oorspronkelijk bericht - Van: Surj [mailto:[EMAIL PROTECTED] Verzonden: vrijdag, juni 13, 2008 09:23 PM Yes the 'java.awt.headless=true' specified as a parameter when starting up the weblogic container, is there any other way of setting this i.e. programmatically during startup. Can you also verify from within your code whether the setting was correctly processed? This you could check via: System.out.print(java.awt.headless= + System.getProperty(java.awt.headless, false)); In theory, you could use System.setProperty(java.awt.headless, true) to set the value, but as is often the case with properties on the system-level, it could be that setting it programmatically has no effect at all. HTH! Cheers Andreas -- View this message in context: http://www.nabble.com/Print-JPEG-HeadlessException---Please-Help-tp17821038p18525612.html Sent from the FOP - Dev mailing list archive at Nabble.com.
RE: Print JPEG HeadlessException - Please Help
Just in case it means something, I ran into this problem when java.awt.headless was specified as true on the startup configuration for the OAS platform. Since we were running on a Windows PC we were successfully able to run Batik (and thereby FOP) by just changing java.awt.headless=false (or removing all together). From my investigation at the time (albeit on FOP 0.20.5 and Batik 1.5beta4), the only way to successfully make it work was to run in a non-headless environment. In short, I did not find a way for FOP (and more specifically Batik) to work in a headless environment, regardless of what you set your properties to. -Original Message- From: Surj [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 4:50 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Print JPEG HeadlessException - Please Help Looks like this is set for sure. I even tried running with Java 1.5. I think I might be beyond help, time to look for a new trade. Andreas Delmelle-2 wrote: - Oorspronkelijk bericht - Van: Surj [mailto:[EMAIL PROTECTED] Verzonden: vrijdag, juni 13, 2008 09:23 PM Yes the 'java.awt.headless=true' specified as a parameter when starting up the weblogic container, is there any other way of setting this i.e. programmatically during startup. Can you also verify from within your code whether the setting was correctly processed? This you could check via: System.out.print(java.awt.headless= + System.getProperty(java.awt.headless, false)); In theory, you could use System.setProperty(java.awt.headless, true) to set the value, but as is often the case with properties on the system-level, it could be that setting it programmatically has no effect at all. HTH! Cheers Andreas -- View this message in context: http://www.nabble.com/Print-JPEG-HeadlessException---Please-Help-tp17821038p18525612.html Sent from the FOP - Dev mailing list archive at Nabble.com. -- CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
DO NOT REPLY [Bug 45104] Possible Thread Safety Problem in FOP 0.93
https://issues.apache.org/bugzilla/show_bug.cgi?id=45104 --- Comment #4 from Jeremias Maerki [EMAIL PROTECTED] 2008-07-18 06:28:59 PST --- Thanks for reporting that, but the problem is limited to 0.20.5. The code indeed has multi-threading issues: https://svn.apache.org/viewvc/xmlgraphics/fop/branches/fop-0_20_2-maintain/src/org/apache/fop/pdf/PDFCIDSystemInfo.java?view=markup Current releases don't have that problem: https://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/pdf/PDFCIDSystemInfo.java?view=markup (In reply to comment #3) Hi, We are using FOP 0.20.5. We have recently started noticing that sometimes PDFs we generate are having problems with font embedding. Some times the CIDSystemInfo section gets written as follows: /CIDSystemInfo /Registry (/CIDSystemInfo /Registry (Adobe/CIDSystemInfo /Registry (AdobeAdobe)/Ordering (UCS)/Ordering ()/Ordering (UCSUCS)/Supplement )/Supplement )/Supplement 000 where as it should be : /CIDSystemInfo /Registry (Adobe)/Ordering (UCS)/Supplement 0 It clearly shows that there are threading issues. I am not sure if this issue also exists in latest version of FOP. Regards Anoop Sehdev -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: PDF full screen mode...
On Jul 17, 2008, at 20:08, Jeremias Maerki wrote: I've been quiet about about this PDF extension so far because I didn't see much harm in doing it in a generic way for some simple name/value pairs. If that goes much further (like doing hacks to produce some complex PDF structures but still forcing it into the generic extension) then I'm a bit concerned. I do prefer the non-generic form I proposed at the beginning on the Wiki. I don't think there will be any problems with PDF/A and PDF/X conformance but the further you go with a generic approach the less control you have if a generated file will be conformant. Please keep that in mind while working on this. Thanks. OK, will do. As a plain and simple rule, I'd make it either one or the other. If the user specifies a conformance level, processing of the extension is disabled, since otherwise FOP cannot guarantee the conformance. I see perfectly what you mean, and the idea of specifying PDF 'expressions' is way too dangerous to allow. That's why I'd like to limit it to a handful of elements that, when combined, can serve to compose simple dictionaries/entries. Obviously, the docs will have to come with a Big Fat disclaimer that users are advised to stick to the examples that we provide, unless they are absolutely certain they know what they're doing... In the meantime, I have received another reply from Bill, which raises some more concerns (something that was already playing in the back of my mind), namely, users that specify PDF 1.6 entries in a document whose header indicates PDF 1.4. Not sure, but this is very likely to cause unpredictable behavior in certain viewers... Some may simply ignore the entry, others might consider the PDF to be corrupt/ invalid. Bill, note that the entry in question may well be available in the ViewerPreferences dictionary as of PDF 1.6, but FOP still produces PDF 1.4 max. Cheers Andreas
