[GUMP] Build Failure - Fop
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2001-08-19/xml-fop.html Build results exceed maximum length.Please see URL above for details. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
SAX
My application which used FOP by fiering SAX event on it stopped working when I updated from FOP 0.19 to FOP 0.20. I used the following code for FOP 0.19: Driver driver = new Driver(); driver.setRenderer(org.apache.fop.render.pdf.PDFRenderer, Version.getVersion()); driver.addElementMapping(org.apache.fop.fo.StandardElementMapping); driver.addElementMapping(org.apache.fop.svg.SVGElementMapping); driver.addPropertyList(org.apache.fop.fo.StandardPropertyListMapping); driver.addPropertyList(org.apache.fop.svg.SVGPropertyListMapping); driver.setOutputStream(myOutputStream); ContentHandler ch = driver.getContentHandler(); // Fire SAX events on ch driver.format(); driver.render(); How do I change this for FOP 0.20? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: pdf security
Thanks for these suggestions,. I think I've narrowed down the problem to font-embedding. If I use Helvetica in my xsl:fo, then I can export to rtf without problems, but using the Arial metrics files I created and embedding these results in garbled rtf output. Viewing the Document properties in Acrobat lists the fonts as multibyte e.g Original Font: 1E3f38Arial Type: TrueType(CID) Encoding: Identity-H Actual Font:Embedded Type: TrueType On the other hand, a pdf using Acrobat Distiller from Word Original Font: Arial Type: TrueType Encoding: Windows Actual Font:ArialMT Type: Type 1 Has anyone else successfully converted a FOP pdf to rtf containing embedded fonts? Could the problem be in the metrics creation? Or is it possible to use the fonts without embedding them? Thanks Ralph Bruno -Original Message- Sent: 28 July 2001 01:06 To: [EMAIL PROTECTED] Subject: Re: pdf security Adobe technical support does exactly what all other big-company support folks do as a first line of defense - blame someone else. In fact, FOP contains precisely zero source code to put an Encrypt key in the PDF document trailer dictionary, and hence it is not possible for documents produced by FOP, out of the box, to have security. If you produce a document with FOP, and look at the document security, not only will it tell you that you can print and copy text to your heart's content, but also that there is no security method. When you say Acrobat 5, I'm guessing you mean Acrobat Exchange. Well, that is the only part of this whole equation that can set security, and so Adobe support lied to you. OK, let's be charitable - they didn't know any better. Given my experience with customer/technical support for big companies that is a very plausible explanation. I'm a bit irritable because I'm just coming off a 12-hour day wrestling with idiosyncracies of a J2EE server which shall go unnamed, and has involved a certain support system for 6 weeks to no avail, so I'm venting a bit at Adobe's expense. They actually deserve the flak to some degree, anyway. Seriously, though, did you inspect the FOP-produced doc using _Reader_? As soon as FOP produced it? Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia At 04:42 PM 7/27/01 +0100, Ralph Bruno wrote: I'm using FOP 0.19 and Acrobat 5, and whenever I try to export my FOP-generated pdf to rtf, all I get are seemingly blank pages, but it is in fact white text on a white background (In case you're wondering, my original pdf is black, red and grey text on white). I contacted Adobe technical support and they've informed me that it's a result of the security settings in my pdf - it's been set for non-copying of text. Obviously the only place it could have been set is in the FOP code. How do I change it to allow copying? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: QUERY: Why doesn't PrintRenderer use the addLine routines for borders.
Hello Struan, It looks as though you must have changed addLine as well to add the border-style, since that isn't in the current version (at least not the one I got from CVS last night.) I'm the one responsible for changing this code in doFrame because when borders are drawn using lines in PDF, it didn't seem possible to avoid pixel errors in the segment joins. This made for ugly table borders. It's also true that the dashed border style is the only one which could be (at least partially) handled using the PDF line operator. Due to the fact that we the doFrame code draws four separate lines instead of stroking a single path, I imagine that the the dashes are not going to work great in all cases anyway. However I understand that you may feel something is better than nothing. Could you submit your modified addLine code as well? We will try to come to some satisfactory solution. (Sorry if you'd already done this; I've been away for a few days and might have missed an earlier message in the stack I went through last night.) Regards, Karen Lease P.S. Also, I believe the 0.20.1 version of FOP should fix the problem you reported in late July concerning vertical alignment in table-header rows when the table was continued. If not, please let me (fop-dev) know! Struan Judd wrote: Instead it uses the fillRect routines. Unfortunately, I needed to have a dashed border (in PDF's) and so put back (well not exactly hence the query) the old ways. Which seems to work fine (for me). If the reason for the change was that some of the other renderers couldn't cope, perhaps their addLine routines could be changed to redirect to the fillRect ones. In any case, could the other line styles please be restored to FOP-PDF. Here is the diff of org.apache.fop.render.PrintRenderer of what I've done (between the ''s): 364c364,365 addFilledRect(rx, ry, w, top, --- addLine(rx, ry, rx + w, ry, top, bp.getBorderStyle(BorderAndPadding.TOP), 365a367,369 // addFilledRect(rx, ry, w, top, // new PDFColor(bp.getBorderColor(BorderAndPadding.TOP))); 367c371,372 addFilledRect(rx - left, ry - h - bottom, left, h + top + bottom, --- addLine(rx, ry - h, rx, ry, left, bp.getBorderStyle(BorderAndPadding.LEFT), 368a374,376 // addFilledRect(rx - left, ry - h - bottom, left, h + top + bottom, // new PDFColor(bp.getBorderColor(BorderAndPadding.LEFT))); 370c378,379 addFilledRect(rx + w, ry - h - bottom, right, h + top + bottom, --- addLine(rx + w, ry - h, rx + w, ry, right, bp.getBorderStyle(BorderAndPadding.RIGHT), 371a381,383 // addFilledRect(rx + w, ry - h - bottom, right, h + top + bottom, // new PDFColor(bp.getBorderColor(BorderAndPadding.RIGHT))); 373c385,386 addFilledRect(rx, ry - h - bottom, w, bottom, --- addLine(rx, ry - h, rx + w, ry - h, bottom, bp.getBorderStyle(BorderAndPadding.BOTTOM), 374a388,389 // addFilledRect(rx, ry - h - bottom, w, bottom, // new PDFColor(bp.getBorderColor(BorderAndPadding.BOTTOM))); TTFN Struan Judd * And so it begins ... ICQ: 4498196 http://neongraal.sf.org.nz mailto:[EMAIL PROTECTED] Voicemail and Fax: +1 (201) 305-1011 x1006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[DO NOT REPLY: Bug 3061] Link 'click' location doesn't take padding-top into account
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3061 *** shadow/3061 Thu Aug 9 10:13:47 2001 --- shadow/3061.tmp.15440 Sun Aug 19 13:37:28 2001 *** *** 30,32 --- 30,36 --- Additional Comments From [EMAIL PROTECTED] 2001-08-09 10:13 --- Created an attachment (id=404) Resulting PDF + + + --- Additional Comments From [EMAIL PROTECTED] 2001-08-19 13:37 --- + Still doesn't work in 0.20.1 - 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]
Re: please help!!!
Hi Eric, Sorry if no one has answered your plea before now. Unfortunately (or perhaps fortunately?) I don't have any problem with the example you sent. I'm using the latest CVS, but if you are using an earlier version of FOP, you probably should try with the latest release which is 0.20.1. I've attached the PDF I generated, using a simple A4 size page master. I assume this is the result you want? It's true that the overflow property isn't implemented yet in FOP, but Yyou shouldn't need to use it here, since the text is just wrapping normally in the table cell. Overflow is really meant for flow objects which won't fit at all on the page and should be clipped. An example would be a large graphic. eric.deandrea wrote: I have a table with 4 columns. One of the cells has text in it that is bigger than the size of the column and the text is over-writing the text in the following cell. How do I stop this? I have this: fo:table fo:table-column column-width=2.625in/ fo:table-column column-width=2.625in/ fo:table-column column-width=2.625in/ fo:table-column column-width=2.625in/ fo:table-body fo:table-row fo:table-cell fo:block text-align=start font-size=10pt line-height=14pt overflow=hidden wrap-option=wrap This is some text in cell 1 that will over-write the text in cell 2. /fo:block /fo:table-cell fo:table-cell fo:block text-align=start font-size=10pt line-height=14pt overflow=hidden wrap-option=wrap This is some text in cell 2. /fo:block /fo:table-cell fo:table-cell fo:block text-align=start font-size=10pt line-height=14pt overflow=hidden wrap-option=wrap This is some text in cell 3. /fo:block /fo:table-cell fo:table-cell fo:block text-align=start font-size=10pt line-height=14pt overflow=hidden wrap-option=wrap This is some text in cell 4. /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table -Eric Eric Deandrea Software Engineer (978) 698-6351 Inforonics, Inc. [EMAIL PROTECTED] 30 Porter Rd. Littleton, MA 01460 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] ericbug.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[DO NOT REPLY: Bug 3059] 0.19.0 'dark grey', 'light grey' borders render black horizontally
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3059 *** shadow/3059 Thu Aug 9 09:18:40 2001 --- shadow/3059.tmp.15539 Sun Aug 19 14:56:11 2001 *** *** 2,9 | 0.19.0 'dark grey', 'light grey' borders render black horizontally | ++ |Bug #: 3059Product: Fop | ! | Status: NEW Version: all | ! | Resolution:Platform: PC | | Severity: MinorOS/Version: Windows NT/2K | | Priority: Other Component: pdf renderer| ++ --- 2,9 | 0.19.0 'dark grey', 'light grey' borders render black horizontally | ++ |Bug #: 3059Product: Fop | ! | Status: RESOLVEDVersion: all | ! | Resolution: INVALIDPlatform: PC | | Severity: MinorOS/Version: Windows NT/2K | | Priority: Other Component: pdf renderer| ++ *** *** 32,35 fo:table-cell border-width=1pt border-color=dark grey ... ! fo:table-cell border-width=1pt border-color=light gray ... --- 32,43 fo:table-cell border-width=1pt border-color=dark grey ... ! fo:table-cell border-width=1pt border-color=light gray ... ! ! --- Additional Comments From [EMAIL PROTECTED] 2001-08-19 14:56 --- ! This isn't a bug. ! Use darkgrey or lightgrey as a single word to set all borders to the same ! color value. Using two words is interpreting this as dark for horizontal ! borders and grey for vertical borders. Since dark or light alone isn't a ! valid keyword, black is being used. ! However, FOP should print a warning about that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
Hi fop and xalan dev, The problem here seems to be that the XSLT document function, when called with a single argument which is a node-set (in the fop case, a single element or attribute node) is now using the current directory as the base URI to resolve relative URI references. It should use the base URI of the node, which would seem to be the base URI of the XML document containing the node. The documents FOP is trying to process are in the same directory as the original XML documnent being processed. I think the FOP XSL is correct, but of course, I could be wrong... Regards, Karen Lease Fairly Fanatic Fopper Sam Ruby wrote: FYI - The following change: http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/templates/FuncDocument.java.diff?r1=1.23r2=1.24 ..causes the following build failure: http://jakarta.apache.org/builds/gump/2001-08-18/xml-fop.html - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: QUERY: Why doesn't PrintRenderer use the addLine routines for borders.
Struan, Oops, I hadn't noticed the second version of addLine taking the ruleStyle since it wasn't being called in the doFrame stuff when I made my change. Duhh. The baseline alignment stuff is harder than the straight after align. Our line-height calculations need to be right before we get into that, so it's probably not coming up right away. Cheers, Karen Struan Judd wrote: Karen, I figured that might be the reason. And yup, at the moment somthing is better than nothing. Also, Nope. No change to the addLine code was needed. I'm currently running the 0.20.1 release with only my patch to PrintRenderer as that's what we'll be deploying here so I haven't seen the current CVS but maybe there's been a change since then. and lastly, I haven't checked the vertical alignment issue as with what I'm doing display-align=after does not achieve the align to the last baseline for different sized font's across table cells, (Whew!) that I needed. Thanks anyway. TTFN Struan Judd * And so it begins ... ICQ: 4498196 http://neongraal.sf.org.nz mailto:[EMAIL PROTECTED] Voicemail and Fax: +1 (201) 305-1011 x1006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Property inheritance (space-before)
From: Arved Sandstrom [mailto:[EMAIL PROTECTED]] 'space-before' is _not_ inheritable in any case, so it is something of a moot point. What you are confusing that with is the possibility of using the inherit keyword, which is a different beast. Hi Arved, Thank you for clearing that up for me. You were right, I saw the word 'inherit' in the spec and didn't read further down to inheritable: . no Joshua -- This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy the message or disclose its contents to anyone. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[ANNOUNCE] XSLT-process 2.1 available
What's new? === This release adds few improvements to the previous release: - the ability to process the result of an XSLT transformation through the Apache FOP processor. - initial integration with the DocBook-XSL project; HTML and PDF generation and viewing from within Emacs of DocBook documents is supported. - support for specifying proxies and additional arguments to the supporting Java VM. What is it? === XSLT-process is a minor mode for GNU Emacs/XEmacs which transforms it into a powerful editor with XSLT processing and debugging capabilities. With this mode you can: - run an XSLT processor on the Emacs buffer you edit, and view the results either in another Emacs buffer or in a browser. - run an XSLT processor in debug mode and view what happens during the XSLT transformation. You can set breakpoints, run step by step into your stylesheet, view global and local XSLT variables and many more. In this mode you effectively use GNU Emacs/XEmacs as an XSLT debugger. - when used with the DocBook-XSL package, GNU Emacs/XEmacs becomes a powerful DocBook processing system. Currently the Saxon and Xalan Java XSLT processors, and Apache FOP are supported, and the mode comes out of the box configured to use them. The package has been tested on XEmacs, versions 21.1.14 and 21.4.3, and GNU Emacs 20.7.1, under both Linux and Windows 2000. The package is free software and is distributed under GPL. The home page of XSLT-process is located at: http://xslt-process.sourceforge.net/ Enjoy, -- Ovidiu Predescu [EMAIL PROTECTED] http://orion.nsr.hp.com/ (inside HP's firewall only) http://sourceforge.net/users/ovidiu/ (my SourceForge page) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
