RE: Cannot Copy Text from PDF
David 'Dox' Shevitz wrote: When I create a PDF with FOP, everything looks fine. However, I am unable to copy selections of text from the PDF and paste it into a Notepad or any other text editor. When I create a PDF from Word (without using FOP), I do not have this problem. This is a known problem with TrueType fonts, documented here: http://xml.apache.org/fop/fonts.html#truetype-metrics under the -enc ansi option. There is no workaround other than using -enc ansi, which limits the characters available in the font. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Creating named anchor spots
William Brogden wrote: I would like to be able to generate a document that has anchor locations that you can jump to from an HTML href like this: href=printables.pdf#Test The names used in internal links like: basic-link internal-destination=Test don't seem to work. How can I generate a marker that will be externally visible? Actually, what you need is something to identify the target, not the link. The basic mechanism is the id property that is available on most objects, but you also need to tell FOP to create a destination: http://xml.apache.org/fop/extensions.html#named-destinations Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: br in XSLFO
Gang Li wrote: Anybody know how can I get a line break like br in HTML? Thanks. Putting a linefeed character U+000A in the content should work, but you have to be careful of the properties that affect it, specifically linefeed-treatment=preserve. (I can't remember whether this works in FOP 0.20.5 or not, but I think it does). The other way is to put an empty nested block, fo:block/ where you want the line break, and I am pretty sure that does work. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: text-indent issue
Kumar Puppala wrote: Can anyone direct me to the code where I can prevent inheritance of the text-indent property in the scenario mentioned below? I would like to make those changes in my local copy of Apache source code (0.20.5) since this would impact our application. Any help is greatly appreciated. It is almost certainly not a problem with the inheritance itself, but rather with the way the layout system signifies which LineArea objects are the first. I would start with the variable isFirst in layout/Area.java and find occurrences in the Block and Line layout that reference it, then work backwards from there. It sure could be something else, but that is my best guess about where to start. (I don't have FOP 0.20.5 set up in a development environment anymore, or I would dig a bit deeper for you). HTH. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Font and image problem
[EMAIL PROTECTED] wrote: I have a strange problem.I have set some custom fonts in the userconfig.xml . In my java code I am using the org.apache.fop.configuration.Configuration.put(baseDir ,baseDir); code to set my base dir. The problem is the fonts are picked correctly but if there is any image in the xml source the transformer is not able to pick it since the above code changes the context path . Does any one have encountered similar problem ? Please help me in resolving this issue. I need both custom fonts and image . Try using the fontBaseDir entry instead of baseDir. See: http://xml.apache.org/fop/configuration.html#summary-key-value Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Out of Memory problem
Manoj_Nair wrote: I think someone asked this question ( inadvertently deleted that email) But how do we programmatically increase the memory size for FOP Java VM? AFAIK, it must be done from the command-line. I don't know of a way to do this from within a Java program. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Embedding Type 1 Polish font - Bayesian Filter detected spam
J.Pietschmann wrote: I do not get anny errors or warnings while running FOP, but I don't think the font has a unicode table. The file generated by PFMReader contains: [...]encodingUnknownEncoding/encoding[...]. I tried to change this to WinAnsiEncoding but the result is the same :( Dealing with PFM fonts is more tricky than with TTF. I defer to the experts. I also will defer to the experts, but my recollection is that FOP 0.20.5 doesn't support any encodings but Adobe Standard and ISO Latin 1, neither of which AFAICT handles the required Polish characters mentioned. Best way to tell for sure is to open the output from PFMReader and see what it was able to do. The standard Type 1 files don't have anything resembling the Unicode tables in TrueType fonts. I haven't delved into the multibyte Type 1 formats enough to know how they are handled there, but FOP doesn't handle those formats anyway. Best bet for FOP 0.20.5 is probably to use a TrueType font, but then you have to live with the encoding limitations there (either WinAnsi or underlying text is scrambled). Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Embedding Type 1 Polish font - Bayesian Filter detected spam
Jeremias Maerki wrote: in WinAnsiEncoding. The real problem is that FOP currently doesn't contain a parser for PFB or PFA files that could parse the character map. I don't know if Victor Mote could use the font with his PFB parser in FOray. If it is a standard Type 1 font file, FOray should be able to parse it, but doesn't yet know how to reencode it for the PDF. If it is a CFF file, FOray would probably say that it doesn't recognize the format. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Page Sequence Master
Kumar Puppala wrote: Thanks Victor for your response. So did you have any alternate approaches to resolve this issue in your application? That depends on what you mean by performance issue. If you have plenty of memory, I don't think your performance speed will be adversely affected by using one page-sequence. If you are running out of memory, probably your least-expensive, quickest-to-implement solution is to run on a machine with more memory. AFAIK, the commercial implementations use more memory than FOP, but that may have changed. Several releases ago, FOP needed to have the entire document in memory, not just one page sequence. So the current state is a vast improvement over that. One of the stated goals for FOP is to be able to process page-sequences of arbitrary size, i.e. limited only by disk space instead of memory. There have been pretty heated discussions among the developers about how best to do this. The trick of course is to come up with a /general/ solution that works or can be made to work for all cases posed. The constraints are significant. Consider the example of a table with auto layout that is 1000 (or 50,000) pages long. You need to know what is going on at both ends of that table to do the auto layout. IIUC, the three rewrite efforts underway each use a different approach, and I don't think any of them are yet complete, so it will be interesting to see what possibilities develop. I wish I had a better answer for you. Your second-best option (see recommended option above) is probably to pick one of the rewrite efforts support it. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: blocks Memory Usage/Performance
Ram Krishnamoorthi wrote: Would like to know if there are any differences (from a Memory Usage and Performance Stand Point) between having Fewer Fo:Blocks with data present in each Fo:Block Spanning Multiple Pages and having More FO:Blocks with less data present in each Fo:Block. In FOP 0.20.5, I don't think there would any perceivable difference in either memory usage or performance. The process is fairly sequential, i.e. encounter a character, place it on a line, repeat. Also, the entire page-sequence is in memory anyway. There are at least three efforts to improve 0.20.5 underway, and this may change with at least some of them. However, I still wouldn't expect it to be significant unless you are talking about blocks whose contents by themselves are bumping up against memory limits, which is pretty unlikely. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Image callback for each page?
Irv Salisbury III wrote: It seemed like most of the readers would read the image into memory. So, one thought on an enhancement might be to always read the bytes in from the URL and then just hand that off instead of opening the URL again. Of course, this doesn't allow for future enhancements where it doesn't need to read the whole thing into memory. Hi Irv: I spent the last couple of days refactoring my graphics package (not FOP, but derived from FOP) a bit. It needed to be done anyway, and your question gave me a good excuse to dive in. The upshot is this: 1. As you have suggested, I have changed most of the Readers (Factories in my package) to open the stream once in most cases, read what it needs, and reset. One of them (I think TIFF) still opens another stream later. That can probably be fixed also, but I don't have time to do it now. 2. More importantly, I replaced all of the class-loading stuff with pluggable factories, which means that you can create your own factory, register it, and, as the URL goes by, have it look at it to decide if it is one of your special cases. If so, create a Graphic instance that talks to your own classes, and you are on your way. The method that makes the Graphic instance (i.e. that manages the Factories) has a boolean that can be set to either cache the instance or not. If you decided to use any of this, you still have the non-trivial task of integrating my work back into FOP's code. It is very doable, but it will probably take some time. I'm not really suggesting that this is an efficient way to go -- I just wanted to let you know that it an option. You can see the code here: http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-graphic/src/java/org /foray/graphic/ Email me off-line if you need help finding out how to download the code. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PDF Transcoder bringing the server down
Saptarshi Sen wrote:
I am trying to convert an SVG into PDF using the PDF
Transcoder in FOP. There are external fonts embedded into the
PDF. FOP has been embedded into our application which runs on
Weblogic. The entire process works fine on my local machine
which runs Win 2k.
However, when I try the same on our integration machine
running Solaris, the call to the 'transcode' process just
brings down my Weblogic server. There is no exception thrown.
The PDF generated is of size 0 KB.
I have no clue as to what is causing this problem. What
are the various details I need to take care of while running
FOP on Solaris?
Based on your description, the likely cause is that Batik can't find a local
graphical environment in which to run on the Solaris box. If Solaris has a
GUI, try running it under that (I am more familiar with Linux which has a
graphical console that can be used for such things). Also, here is some code
that can be used to check *before* running a task requiring a graphical
environment:
/**
* Determines whether this environment can support graphical functions
that
* are required for system fonts, Batik (SVG processing), and other
* AWT-dependent systems. The result returned here is somewhat different
* from that returned by [EMAIL PROTECTED]
java.awt.GraphicsEnvironment#isHeadless()}.
* Some environments that are not headless, i.e. that support a mouse,
* keyboard, and display, are nevertheless not graphical. A Unix/Linux
* terminal is a good example.
* @return True iff a local graphical environment can be created.
*/
public static boolean isGraphicalEnvironment() {
GraphicsEnvironment ge = null;
try {
ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
} catch (LinkageError e) {
return false;
}
return true;
}
HTH.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Image callback for each page?
[EMAIL PROTECTED] wrote: We have an api that generates a sort of barcode image that needs to be put on the bottom of each page. However, each image is unique and needs to be generated with some information from the xml document. I know I can do this by using a REST api call and putting a URL in the fo:graphic that dynamically generates the image. However, I'd rather do it right in the Java code that sets up the Driver. So, is this possible? Some thoughts I have, but don't know if they exist: My guess is that markers with a URL would be the easiest and most standard way to do this. But I'll take your word for it that you want the callback. 1. Can I get a callback that calls my Java code when a certain fo:graphic element is hit and let me dynamically put the XSL:FO content in there? This would allow me to dynamically generate the images on the fly and put the appropriate image content in . I think you can do this, but again, it seems like a pain. IIRC correctly, the FONode class has a getParent() method which can be used to recursively go up the tree until you get to the Root (keep in mind that this is XML/FO inheritance, not Java inheritance). I would cache the object that will generate the image in Root, and, if it does not exist already, write an FONode method called getRoot() which will recursively go up the tree to Root and return Root. Then, you'll need to modify the code that creates the image in the AreaTree, and then use your (presumably) ExternalGraphic node to do something like the following: YourGraphicMaker ygm = externalGraphic.getRoot().getYourGraphicMaker(); Image image = ygm.makeGraphic(externalGraphic); // pass the image instance where it needs to go. I have used the above technique successfully to handle global items like loggers and subsystem servers. 2. Can I put custom xsl:fo elements in the document and then register my own renderers for dealing with those types? The renderers are more oriented toward a given output medium, so you are more likely going to be modifying or extending one to handle your custom elements, but yes, this general technique could work as well. My guess is that this is probably even more of a pain than option 1 above. Some information is here: http://xml.apache.org/fop/dev/extensions.html Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Image callback for each page?
J.Pietschmann wrote: The problem is that some stock image readers only accept a stream with the pointer at the begin of the content, and if the stream pointer can't be reset (e.g. if the analyser needed so much info that the underlying implementation already discarded buffers), then the stream has to be reopened. If you want to donate an intelligent buffering system BufferedInputStream (and all InputStreams) have mark() and reset() functions which should work for this. I rather thought that the developer maybe didn't want to leave the stream open in between layout and rendering, but I don't know. WRT intelligent buffering system, I wrote one for my font work, based on java.io.RandomAccessFile with a wrapper of my own that allows you to read in bigger chunks at a time with a kind of window that slides back and forth over the file contents. I haven't looked at the ImageReader subclasses to know whether they really need a random-ish approach or whether resetting the Stream would be sufficient. If you are interested, the source is here (the inner class ByteSearcher is where the sliding window is managed): http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-common/src/java/org/ foray/common/RandomReader.java?view=markup I don't really have a good feel for how efficiently this works. It seems to work pretty well, but I haven't profiled it. Of course, FOP is always welcome to this code. Also, if Irv does donate some other intelligent buffering system, he needs to understand that the FOP developers won't use it unless it is written for the head/trunk. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiple page sequence without page breaks
Louis.Masters wrote: In order to get around some memory issues, I am creating multiple page sequences on my reports. The problem is, every time a new page sequence is created, a new page is created. Is there any way I can tell FOP not to insert the page break after the page sequence? I know it sounds _funny_ to not have page breaks when there is a new page sequence, but I am just using the page sequences to break up the memory use in FOP. No, there is no way to do what you are trying to do. Even putting the practical aspects aside (which are overwhelming), it would be a violation of the XSL-FO standard. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: create arabic pdf
nafise hassani wrote: Anybody knows how to Create PDF with Arabic words? Seems FOP-0.20.5(cocoon use it in its pdf serializer) cannot handle Arabic glyphs/ligature properly. It can only display the Arabic characters but the rules to ligate them together cannot be displayed. also it show chars from left to right but arabic is a right to left language AFAIK, none of the open-source FO implementations handle either the bidi issue or the ligature issue correctly. To handle the ligatures properly requires (I think) the use of the OpenType GPOS tables. The commercial implementations are your best bet right now. I think that RenderX handles the bidi issue, but not the ligature issue correctly. I don't know about Antenna House, but you might check with them as well: http://xml.apache.org/fop/resources.html#products-other Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: create arabic pdf
nafise hassani wrote: I use cocoon as framework and cocoon use FOP to produce pdf output so I need a way to make fop to create arabic pdf I am not sure, but I think it should be possible to drop one of the commercial implementations into Cocoon. Other than that, the best solution would seem to be to contribute to the open-source work. Neither of the issues that you mention is easy to solve, and it is likely to be some time before an open-source solution is available. If you need a solution today, I think you have to look at the commercial implementations. BTW, in my previous posting I used the word bidi where I meant writing-mode. The answer is the same. Sorry for the confusion. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problem with br/ tag
[EMAIL PROTECTED] (Rohit) wrote: Hi, I have an HTML content which I am converting to PDF using FOP.I have problem with the carriage retrun tag br/. The new lines does not appear in the PDF. Any one has any idea abt it ? Please reply. There is no br element in the fo: namespace. IIRC, you can accomplish the same thing with an empty fo:block/ element: fo:blockText on first line.fo:block/Text on second line./block Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: fop servlet question
Vojko wrote: The last thing I need...is that my servlet runs with -c userconfig.xml where I defined font metrics files. I think you'll have to do that programmatically: http://xml.apache.org/fop/embedding.html#config-external Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problem converting TTF using TTFReader
Partridge, Michael wrote: Thank you for your reply; unfortunately I got the same output when giving TTFReader the '-enc ansi' option. [EMAIL PROTECTED]$ java -cp ~/src/fop-0.20.5/build/fop.jar:~/src/fop-0.20.5/lib/avalon-fra mework-cvs-20020806.jar:~/src/fop-0.20.5/lib/xercesImpl-2.2.1. jar:~/src/fop-0.20.5/lib/xalan-2.4.1.jar org.apache.fop.fonts.apps.TTFReader -enc ansi ~/fonts/OCR/OCR-A.TTF ~/fonts/OCR/OCR.xml TTF Reader v1.1.1 Reading /home/mpartridge/fonts/OCR/OCR-A.TTF... Number of glyphs in font: 115 Unicode cmap table not present java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:507) at java.util.ArrayList.get(ArrayList.java:324) at org.apache.fop.fonts.TTFFile.createCMaps(TTFFile.java:449) at org.apache.fop.fonts.TTFFile.readFont(TTFFile.java:439) at org.apache.fop.fonts.apps.TTFReader.loadTTF(TTFReader.java:222) at org.apache.fop.fonts.apps.TTFReader.main(TTFReader.java:184) I've been searching for ways to generate a Unicode cmap table and I've found tools to translate cmap tables but nothing to create one in an existing font. If anyone knows of an app that can do this, please let me know. The tools that I use are FontLab (commercial): http://www.fontlab.com/html/fontlab.html and TTX (open source): http://sourceforge.net/projects/fonttools/ You can do almost anything with TTX, but it requires some knowledge of the font file formats. FontLab is going to be pricey if this is all you need it for. Support for other encodings could be added to tools like FOP, but that is likely to be even pricier. Best solution that I can think of is probably to just purchase a different font (or hire someone to fix the existing one -- but watch out for licensing issues). Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PFMReader OutOfMemory
Nate Gelbard wrote: I was able to use PFMReader w/ the Cyberbit.ttf font to create the XML file for FOP. I found that this font did not contain the typefaces I desired and found a Arial Unicode MS TTF file instead. Arialuni.TTF 24megs (download) http://zsigri.tripod.com/fontboard/cjk/cjksupp.html When I run this file through PFMReader, it generates an out ^ of memory exception. -Xmx512m on a P3 Linux box (512Mb) - failed -Xmx768m on a P4 XP box (1024Mb) - failed -Xmx3000m on a SunFire 280R (8096Mb) - failed How is it that a 24meg font file is requiring that much memory to process? Do you mean TTFReader? If you are really running it through PFMReader, that might be the problem. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PS render, fonts, embedding
Jacek Wojcik wrote: Thanks again. We have one more question. Could You please point out someone (maybe You) who can add this feature to FOP library (creating PS files using ISO-Latin-2 fonts without using any external programms or installing fonts directly on printers etc.) as we are not familiar enough with PostScript to do this. How much would it cost? Is it possible to achieve in a month time since now? All we need is jar file (or part of it) easily exchangeable with one of 0.20.5 release. If Jeremias can help you in the time frame you want, that is probably your best option. If not, please contact me off-list for another possible solution. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PS render, fonts, embedding
Jacek Wojcik wrote: Thanks again. We have one more question. Could You please point out someone (maybe You) who can add this feature to FOP library (creating PS files using ISO-Latin-2 fonts without using any external programms or installing fonts directly on printers etc.) as we are not familiar enough with PostScript to do this. How much would it cost? Is it possible to achieve in a month time since now? All we need is jar file (or part of it) easily exchangeable with one of 0.20.5 release. Sorry, I should also have mentioned that the commercial applications may be able to do this as well. I think RenderX XEP has Type1 support for their PostScript renderer. They have a new release due out in October, I think. Other commercial applications may support what you want as well, but I am not familiar with them. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Forcing use of ASCII85Decode
Simon Kitching wrote: I have a c application which has been generating PDFs by executing the fop.sh script. I have now rewritten the process in Java, and am using the o.a.f.apps.Driver class directly. However the old code used to produce PDFs which contained only printable characters (some sections look like base64 encoding). The new code produces sections which contain binary data. For various reasons I need to ensure that the PDF output contains printable characters only, like the old solution did. The old PDFs include lines like this: /Length 1917 /Filter [ /ASCII85Decode /FlateDecode ] while the new ones have lines like this: /Length 1474 /Filter /FlateDecode At a guess, I would say that with my old app (using fop.sh) the non-printable data has been deflated then ascii85-encoded to render it into all printable chars (probably at a filesize penalty), while the new code (calling Driver directly) skips the ascii85 encoding step. Assuming this is the case, can anyone tell me how to enable the ascii85-encoding of data within the PDF, using the o.a.f.apps.Driver API or similar?? I'm using fop 0.20.5 in both the old and the new code, though in the new case I'm possibly using some updated libs. Here's the java Code I currently use to invoke the Driver: Driver driver = new Driver(); driver.setLogger(fopLogger); driver.setRenderer(Driver.RENDER_PDF); ByteArrayOutputStream baos = new ByteArrayOutputStream(); driver.setOutputStream(baos); DocumentInputSource documentInputSource = new DocumentInputSource(msg); driver.setInputSource(documentInputSource); driver.run(); return baos.toByteArray(); This is not documented, but you can choose the filters applied using the following configuration file construct: entry role=pdf keystream-filter-list/key list valuefilter-keyword/value /list /entry The filter keywords are: flate, ascii-85, and ascii-hex. To apply multiple filters, list them in the order they should be applied: entry role=pdf keystream-filter-list/key list valueascii-85/value valueflate/value /list /entry To apply *no* filters: entry role=pdf keystream-filter-list/key list /list /entry Now, the second part of the question is how to set the configuration through your program. The beginnings of the answer are here: http://xml.apache.org/fop/embedding.html#config-internal However, that only documents setting the standard configuration. The method you will need is this one: public static void put(String key, Object value, int role) The valid role values above are Configuration.STANDARD, Configuration.PDF, and Configuration.AWT. You want Configuration.PDF. If you only have one filter to apply, skip the list concept and just drop the name of the filter in to the value: Configuration.put(stream-filter-list, ascii-85, Configuration.PDF); If you need the list, build a java.util.ArrayList with the multiple entries and use it in the method. Something like this: java.util.ArrayList list = new java.util.ArrayList; list.add(ascii-85); list.add(flate); Configuration.put(stream-filter-list, list, Configuration.PDF); There is a strong possibility that I have some of the details wrong here, but this is the gist of it. Let me know if this doesn't work or if you have to make changes to get it to work. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Development Version: xml+xsl - fo - rtf
Clay Leeds wrote: RTF This is currently not integrated with FOP but it will soon. This will create an rtf (rich text format) document that will attempt to contain as much information from the fo document as possible. If any of the fop-devs knows more about getting FOP to output to RTF, it would be great to update the web site to make the above actually contain useful information. I checked CVS for RTF support is much more robust in the development branch, thanks mostly to the jfor crew, led by Bertrand Delecretaz, and Peter Herweg's efforts to integrate it. However, since releases are not being made from the development branch yet, users will have to download and build it themselves, at their own risk. the FOP Output Target page (from whence the above quote was taken), but couldn't find any information on the subject. The RTF-related info appears to have either been entered into the FOP Output Targets page before it was brought into CVS, or it wasn't well-documented. The web site, of course, refers to the released versions, and is accurate. WRT the source file, I don't follow. I can see the content here: http://cvs.apache.org/viewcvs.cgi/xml-fop/src/documentation/content/xdocs/ou tput.xml?rev=1.16only_with_tag=MAINview=markup at line 240. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Development Version: xml+xsl - fo - rtf
Johannes Franz wrote: Ok, i created a fo file, with a preprocessor from xml+xsl. Now i tried: [EMAIL PROTECTED]:~/xml-fop ./fop.sh protocol.fo -rtf bittebitte.rtf and get the following error message: 16.06.2004 18:18:54 org.apache.fop.apps.Fop main INFO: 1.0dev Exception in thread main java.lang.NullPointerException at org.apache.fop.apps.Driver.render(Driver.java:544) at org.apache.fop.apps.Fop.main(Fop.java:71) What did i do wrong? Probably nothing. However, this is the at their own risk that I mentioned. I haven't looked at that code for about six months (it worked then), but you probably caught it at a (hopefully temporarily) unstable moment. Perhaps one of the developers active on the trunk can give you a better answer. This actually looks like a higher-level problem, i.e. I don't think it is even getting as far as the RTF code. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Development Version: xml+xsl - fo - rtf
Clay Leeds wrote: On a related note, I found the FOP site's RTF I couldn't find before[1] (it was 'hidden' on the /fop/dev side). Also, I Be careful here. There are two components in play. One is the rtflib stuff, which you find on the /fop/dev side. The other is the RTF renderer which uses rtflib to generate the RTF document from FOP. They are deliberately kept separate, because rtflib is useful for other things besides FOP, and should not be at all dependent on FOP. That is why it is listed on the dev web page as a subpackage. It could be (and IMO should be) kept independent. At least this is the way it was about six months ago. This goes very much to the modular/monolithic debate on fop-dev, and perhaps this has been changed by active developers since I last saw it. But I would be careful about how you document it. The rtflib documentation really *is* of interest only for developers. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: fo:float
Chris Bowditch wrote: I took a peek in the font XML file. I'm not sure how to use that data. One particular font (Courier) had a width of 600 for most of its characters. I wasn't sure what that 600 meant, and how to transfer that to pixels, inches, etc (I guess the font size would have to be used too). measurements in FOP are typically 1/1000th of a Point. However, when dealing with Fonts the measurements in the metrics need to be adjusted according to required Point size. Hence they are unlikely to be physical measurements like pt or mm. I would imagine 600 meant 0.6em here. Perhaps one of the committers can be of more help here. Yes, that is correct as a practical matter. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Japanese fonts do not appear in desired weights
Graham Hannington wrote: Gotcha, thanks. I think this is what JPFOP, er, kludges (no disrespect intended to the developer). From the JPFOP site: renderInlineArea() method was modified. ... For Bold, the characters are rendered 4 times with offset. If I read this correctly, and JPFOP is doing what I think it's doing to emulate a true bold weight, then: ingenious, but... yeurch! ;-) A more elegant (if you like, proper) solution, as you say, would be to get a font that actually contains the different weights. I'm looking at: http://www.ricoh.co.jp/swd/font/valu-d2/wabun/index.html Yes, printing the glyph 4 times might be acceptable for printing, but not for searching or indexing. See also: http://www.adobe.com/type/browser/C/C_japanese.jhtml Also, keep in mind FOP's current limitations WRT fonts in general: http://xml.apache.org/fop/fonts.html Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Scaling images
Richard Sweeney wrote: fo:table-cell fo:block fo:external-graphic src=url(/stylesheets/ING.bmp)/ /fo:block /fo:table-cell I think this is what you are looking for: http://xml.apache.org/fop/graphics.html#resolution Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unkown font error driving me crazy
Mike Ferrando wrote: Jerry, 1. the userconfig file must be in your command line: C:\FOPfop -c conf\userconfig.xml -fo myfo.fo -pdf mypdf.pdf 2. The Myfont.xml file must be in the same folder as your fop.bat file. Actually, there is now a fontBaseDir config option. See: http://xml.apache.org/fop/configuration.html#summary-key-value 3. The Myfont.xml file must be created using the jar. I usually copy the font into the same folder as the fop.bat then I run the command line to transform it into the myfont.xml file. Here is the command line (you will have to edit the file names to match the ones you are currently running in your batch file): java -cp build\fop.jar;lib\avalon-framework.jar;lib\xml-apis.jar; lib\xercesImpl.jar;lib\xalan.jar org.apache.fop.fonts.apps.TTFReader [options] cmr10.ttf ttfcm.xml See also: http://xml.apache.org/fop/fonts.html#truetype-metrics Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Performance PDFRenderer vs. PCLRenderer
Andreas L. Delmelle wrote: -Original Message- From: Michael Reiche [mailto:[EMAIL PROTECTED] On søn, 2003-11-02 at 14:39, Andreas L. Delmelle wrote: Well, the FOP Output Targets page (http://xml.apache.org/fop/output.html) does indicate that SVG support for the PCL Renderer is somewhat limited. As far as my testing have been done, I found following errors (or missing features) in the PCLRenderer: No SVG! Could be... I have never needed PCL output so far, and I have at the moment no PCL printer at my disposal, so I can't confirm That's why I'm sending this in CC to the fop-user list. Maybe over there, someone has more experiences to share ? If SVG support for PCL is really *that* limited, this should definitely be mentioned on the website. http://xml.apache.org/fop/output.html#pcl-limitations says SVG is not supported. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Changing SAX Class
Andreas L. Delmelle wrote: just white-space-treatment=preserve alone it has no effect and The FOP compliance page (http://xml.apache.org/fop/compliance.html) indicates only basic conformance for this property... No -- the FOP compliance page indicates *no* conformance for this property. The blue in the basic column means that, because this property is not required for basic XSL-FO conformance, FOP is conformant with the XSL-FO standard basic level WRT this property. Hmmm. This is now the second time in mere days that this has confused even our most able users. I find the color-coding extremely useful, but if it is confusing everyone, perhaps we should remove it. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Converting to uppercaseusing text-transform
Clay Leeds wrote: According to the FOP Compliance page (watch wrap): http://xml.apache.org/fop/compliance.html#fo-property-text-transform There is basic support for text-transform, but extended support is not available. I clicked on the §7.16.6 link: Nope, that is not what that means. The basic and extended columns refer to the spec itself, which has three levels of conformance. The no means that FOP does not support it. The blue in column 1 means that FOP is conformant with the spec on this issue for the spec's basic support. In other words, FOP passes a conformance test for basic XSL-FO support WRT text-transform, but only because support for text-transform is not required for basic XSL-FO support. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Converting to uppercaseusing text-transform
J.Pietschmann wrote: Abhijit Junnare wrote: I looked through the FOP documentation and it says that the text-transform property is NOT yet implemented in FOP. I am wondering if there is any chance that this will be implemented in FOP and if yes how long would it take. The spec itself recommends against using this feature. Uppercasing arbitrary Unicode letters is a quite non-trivial task. There are some use cases where it is very helpful to have this feature (titles of books and chapters for example). It has been implemented in the trunk, a bit klunkily and needing work, but the basics should work. I would be glad for people to use it and test it and let us know of exceptions to the structure that is there. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Failed to read font metrics file
J.Pietschmann wrote: Andreas L. Delmelle wrote: Problem 2: The better solution is to eliminate the font-metrics file completely, have the config point to the font file itself, and read the font file on-the-fly to get the metric information. ... I like this idea even better... I always wondered why you first had to generate the metrics file This is in the archives. The point is that you can edit the metrics files, and there are fonts out there which actually need this. My recollection is, that in some cases anyway, the metrics file may be bad because our font-reading application is incomplete, which should be fixable. Even if the font file itself is the culprit, my knee-jerk reaction is that the best thing to do is to have the user edit it with font-editing software, and to address the problem at that level, rather than trying to have FOP work around it. I don't know of any other software that tries to allow the user to adapt the font the way are doing now. However, ... Of course, we could have both. ... I have no big problem with this. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Failed to read font metrics file
Andreas L. Delmelle wrote: -Original Message- From: Rob Stote [mailto:[EMAIL PROTECTED] What Isabelle was struggling with was a lack of understand of how to use, and generate a metrics file. This can easily be solved by telling her RTFM, pardon my bad language. You have provided an excellent resource on you website on how to use the classes in FOP to generate the metrics file you need for use inside FOP. Yes. Only perhaps we should provide a description on how to start the command-prompt :-) http://xml.apache.org/fop/fonts.html#type1-metrics http://xml.apache.org/fop/fonts.html#truetype-metrics Do you have suggestions for improving the above? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Failed to read font metrics file
J.Pietschmann wrote: I'd like to see *one* program for handling metrics, dealing with PFM, TTF and TTCs intelligently, but integrating it into the main CLI goes a bit beyond the one tool for one purpose principle which should apply to the FOP CLI as well. This is not very difficult to do, and I have much of it done already, but there are some issues: Problem 1: There is no place to check it in. Nobody wants to do another release from the maintenance branch. There is no way to use it or test it in the trunk, until we at least get configuration working again. Also, until we get a usable layout system in trunk, such a change does no good. Further, until all integration work between the two branches is complete, any changes to either one make an ugly mess. Problem 2: The better solution is to eliminate the font-metrics file completely, have the config point to the font file itself, and read the font file on-the-fly to get the metric information. I don't think this is going to be very hard to do either. Of these two problems, the first is the bigger. I have been working on FOP for over a year now, and at no time in that period has there been a way to improve a usable version of FOP without 1) hacking the developer base off, and 2) causing even wider differences between the two development lines. I am neck deep in a project right now to try to correct this problem, but it is too early to tell whether it will ultimately be successful. Once that is done, I hope that we will do a release that is merely for integration (i.e. no new features, just test and make sure we haven't gone backwards). *After* that, fonts are at the top of the priority list (mine anyway), and Andreas is welcome to do as much of it as he likes. We have a wide range of under-the-hood improvements planned, as well as items like the above that should simplify using fonts. I just want to make sure folks don't think we are ignoring these things. We are actually making some progress, although it seems slow and painful. I could double my productivity if I could stop cursing the decision to split the development into two lines. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java script with xsl in FOP ?
Abhijit Junnare wrote: Is it possible to use javascript inside the XSL that will be used with FOP. I need to do some calculations and so I need this. Is there any other way to do some basic math or some string manipulation? I know the string functions in xsl but I am afraid they wont solve my problem. Any help if appreciated. (This is really an XSLT question.) I haven't ever done it with javascript, but I understand that it can be done. See the bottom of: http://groups.yahoo.com/group/XSL-FO/message/3857 where a method for using java in XSLT (to get today's date) is demonstrated. Note also that this must be dependent on your XSLT engine, so check its docs or mailing lists for more specific information. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java script with xsl in FOP ?
Abhijit Junnare wrote: YES. The output will be pdf. So I dont want to proceed if I know that it wont work in the future. So I am asking everyone so that I can think what I should be doing. The eventual output is not so much the issue as whether you are trying to pass the code *through* XSLT to the output (i.e. embedding javascript in your html or pdf document), or whether you are trying to use the javascript within the XSLT transformation itself for purposes of outputting (in your case) XSL-FO code. I understand you to be doing the latter, in which case the technique I posted earlier will work *with java*, and you should be able to find a way to do it with javascript as well, at least with some XSLT engines. Certainly it is better to use pure XSLT if you can as that will be more portable. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: how to add font collections to FOP??
Robert P. J. Day wrote: On Sat, 6 Sep 2003, Victor Mote wrote: Robert P. J. Day wrote: the docbook FO stylesheets have a parameter xsl:param name=monospace.font.family select='monospace'/ that i'd obviously like to change to reflect the vera fonts for now. but this seems to require being able to refer to that collection of font metrics files by a single name. is this what is referred to as a TrueType Collections Font Metrics that i see on the FOP fonts page? No. I am not familiar with the DocBook stylesheets, but it looks like they are just defining a base font to which variations can be applied within the stylesheet. hmmm ... i asked someone who's quite the authority explicitly about this, and he seemed adamant that, if i wanted four variations of a font (in my case, VeraMono), i had to add four individual font entries to the configuration file. that is, one for regular, one for bold, etc. Well, your authority is correct, but that is not even close to what you asked. You appear to have three topics confused: 1) The way the DocBook stylesheet creates font information in the XSL-FO it generates, 2) the process for creating font metrics files for FOP, and 3) the registration of the fonts and metrics with FOP. I have already given you a couple of ideas about how to follow the first topic. The other two are (I think) well covered on the FOP web site. i'll check back with him and press him a little more closely on this, since it would be ideal if a single base font could be used here. but i was sure he told me that's not the way it worked, at least for docbook. if i track this down, i'll let you know. Some software can use a base font to mimic bold and italic. FOP has no such mechanism, and the results are never high-quality when that approach is used anyway. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: how to add font collections to FOP??
Robert P. J. Day wrote: the docbook FO stylesheets have a parameter xsl:param name=monospace.font.family select='monospace'/ that i'd obviously like to change to reflect the vera fonts for now. but this seems to require being able to refer to that collection of font metrics files by a single name. is this what is referred to as a TrueType Collections Font Metrics that i see on the FOP fonts page? No. I am not familiar with the DocBook stylesheets, but it looks like they are just defining a base font to which variations can be applied within the stylesheet. The TrueType Collections refers to a font file format in which more than one logical TrueType typeface is stored in the same physical file. In the previous part of your post (not copied here) it sounded like your fonts were in .ttf format, which means that there is one logical font in each file, and you don't need to worry about the .ttc stuff at all. i just want to be able to say, monospaced fonts are all now vera, and have the appropriate variation (regular, bold, ...) chosen for that rendering automatically. The DocBook stylesheet probably does this automatically. If it doesn't work properly, look at the intermediate fo file or the stylesheet itself to see what it is doing, and adjust accordingly (possible adjustments would be to the stylesheet itself, or manual adjustments to the font metrics file itself). Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IPD
Marcelo Jaccoud Amaral wrote: By the way, point is a terrible measurement unit, because in typography there are three kinds of points: - the Anglo-Saxon point = 1/12 pica = 0,013835 in = 0,3514 mm (no, it's not exactly 1/72 in !!) - the Didot point = 0,3759 mm - the Fournier point = 0,3487 mm I don't really want to jump into this discussion, but since I was the one that used 72 points per inch in a calculation related to this thread, I must. There is at least one more definition of point, whether created or merely adopted by Adobe, I don't know. Both PostScript and PDF use 72-units-per-inch as the default definition for the size of a unit of user space. This is commonly called a point, and is the basis for FOP's sizes, and therefore AFAIK, the answer I previously gave was correct. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IPD
Chris Bowditch wrote: Now my question: What is the exact conversion between IPD and pt or px and so on? The value ipd says nothing for me. IPD stands for Inline Progression Dimension. In some cases this equates to width, but this is not true in general, if reference-orientation is non-zero (not implemented in FOP), then Inline Progression Dimension can become height. I think the unit of IPD is millipoints, but I am not 100% certain, perhaps one of the committers can confirm or deny this? I believe that is correct, so, from the original post: 52 millipoints = 520 points = 7.22 inches = 18.34 cm 507402 millipoints = 507.402 points = 7.047250 inches = 17.900015 cm Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error when placing svg into xsl with fo:external-graphic
Benjamin Wischek wrote: I'm trying to put a svg-file into my xsl-file and then let it run through FOP. The svg is a barcode example from krysalis barcode homepage. I used the fo:external-graphic command: fo:block fo:external-graphic src=example-code39.svg/ /fo:block I'm not sure whether this is your problem or not, but make sure that FOP can actually find the file. See: http://xml.apache.org/fop/fo.html#external-resources for documentationa about specifying the external resource as a URI, including the instructions about setting a base URI. If that doesn't solve the problem, open the file and make sure it actually has some SVG code in it, and that there is no obvious namespace problem. Beyond that, we'll need to get someone with more Batik expertise to answer. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can't install my font!
Christoph Rupp wrote: That's it! I wasn't able to load the configuration file. Well - it was loaded, but at the bottom of the file there was another fonts /fonts section which was empty, so my previous setting were lost... my fault... It works now, thank you very much (and thanks to all of you who tried to help me!) I'm glad your problem is solved, but this means our documentation (and my understanding of what is going in with the AWT renderer) is wrong. It will be a few days at least before I can get to it, but I'll try to find out what is going on there get it documented correctly. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: number-columns-spanned ignored
Psi Aushilfe3 wrote: Does number-columns-spanned attribute work when you generate a PDF? It works Yes. ...as I mentioned, jfor is _very_ buggy :-(( I am confused. AFAIK, FOP 0.20.5 is not related to jfor at all. Did you send your original inquiry to the wrong list? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: absolute-position bug?
Sells, Fred wrote: I need to use absolute-position to put an address in the right spot for a window envelope. I tried the following using fop 0.20.5. I cannot seem to get it to move from the top-left corner of the flow. What am I missing? Probably: http://xml.apache.org/fop/compliance.html#fo-property-absolute-position where absolute-position is described as not being implemented in FOP. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to use a calculated url?
William L. Gibson wrote:
I wish to use fop-0.20.5rc3 to process an XML doc using an XSL
stylesheet that contains both XSLT and FO directives. I extract an
itemNumber from the XML, save it in an XSL variable, use it to
dynamically build a url to an external servlet that will return a jpeg
barcode for that item number. I store the calculated url in an XSL
variable. Finally I wish to use the FO external-graphic to place the
servlet generated image into the output pdf document, but I can't figure
out any way to put the calculated url into the src attribute. It seems
to only accept a string literal.
Is there any way to do what I want (use a calculated url to insert an
image generated by an external servlet)?
xsl:variable name=itemNumber
select=ReportData/Record/structItemRecord/core/structItem/strItem
Number/
xsl:variable name=calcUrl
select=concat('http://www.javabarcoding.com/servlet/lin?BARCODE=',
$itemNumber,
'amp;BAR_HEIGHT=1amp;CODE_TYPE=CODE39amp;X=0.03amp;CHECK_CHAR=
Namp;CHECK_CHARINTEXT=Namp;CODE128_SET=0
amp;HEIGHT=100amp;WIDTH=400')/
fo:block text-align=leftfo:external-graphic
src=url()//fo:block
I'm not sure I'm following your question. Are you trying to do this?:
fo:block text-align=left
fo:external-graphic
xsl:attribute name=src
xsl:value-of select=$calcUrl/
/xsl:attribute
/fo:external-graphic
I'm not really fluent in XSLT, but the above seems to be the concept you are
looking for. The syntax may need some work.
BTW, pure XSLT questions like this kind of risk getting ignored on this
list. See:
http://xml.apache.org/fop/maillist.html#fop-user-policy
for more information, and see:
http://xml.apache.org/fop/maillist.html#xslt-mulberry
for an XSLT-specific mailing list. And see:
http://xml.apache.org/fop/resources.html#documents-xslt
for a list of XSLT books and other resources that you may find helpful.
By the way, the url function that is shown in some fop examples used
inside the src attribute as above must be a fop specific function or so
it seems to me. Where can I find documentation on such fop functions?
See:
http://xml.apache.org/fop/fo.html#external-resources
where the syntax is described, with links to the appropriate underlying
standards. It is possible that some of the example files are not up-to-date.
If you can be more specific, we'll work on getting them fixed.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: keep together pages
Todtenhaupt, Susann wrote: I'm producing TXT through XSL:FO and FOP. If there're more than one page there's following effect: Between the pages there's a break of several lines. I didn't find a property to suppress this pagebreak. The TXT output is laid out on the page just as it would for PDF, then converted to text. I suspect that the blank lines are the layout's way of mimicking the margins at the top and bottom of a printed page. Try eliminating (or making very tiny) the regions and margins at the top and bottom of the page. See http://xml.apache.org/fop/output.html#txt for more details. Another alternative is to simply use an XSLT transformation to get your text output. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with fo:basic-link and fo:block-container
Julian Reschke wrote: I've got an example that still doesn't work with 0.20.5 (basic-link content is a page ref, and it occurs in a two-column layout). Does is make sense to pursue this further, or will I have to wait for the new design FOP? I've got an example that fails with leaders as well. I can't speak for the other developers, but I don't intend to invest any time fixing it in the maintenance branch. The critical thing from a development standpoint right now is to get back to the place where we are only developing on one branch. We are attacking that problem from several different angles right now, all of them on the trunk. About the only thing that will drag me away from that task right now is helping users and developers get up to speed, i.e. documentation. Once we get back to one line of development, we can work on both bugs and features in a much more sane environment. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: bookmark extensions problems
Clay Leeds wrote: I'm having problems getting my Bookmarks to work. I've attempted to follow the instructions here without success: Do the PDF outline items show up, and the links not work, or do the PDF outline items not show up at all? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: image scaling
Koes, Derrick wrote: I apologize. I used a concrete example to describe an abstract problem. I actually do not know the size of the image. Why I do want is for it to maintain its scale inside a 3inX3in block. Here is the doc on this subject, which I think will answer your question (and is consistent with the previous answers): http://xml.apache.org/fop/graphics.html#resolution Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status of MIF Output
Timo Haberkern wrote: can anybody tell me the status of the MIF output renderer. I read in the documentation that it is not fully implemented, but whats implemented and what is not? Does anybody use it in a productive way? Almost nothing is implemented. It creates the master pages and can put fo:block elements into paragraphs, but that is about it. The infrastructure is in place to do a lot more. However, since Frame 7.0, all Frame users have the ability to directly manage the semantic XML document, so there is not much interest. Unless funding is provided along the way, I think it will be one of the last things to be addressed. Also, if a developer came along who wanted to work on it, we could provide some assistance. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: outline
Peter Menzel wrote: I just used the outline element from the fop xtensions and its works fine, but i have one problem. My fo document is (of course :) ) created by an xslt transformation and not everytime all the document parts that are referenced by the fox:outline will be in the document at all. But the bookmark entries still appear in acrobat. Is there a way to make them invisible when there is no formatting object with the refernced id? Not that I know of. However, you should be able to find a solution to this at the XSLT level. If the element that drives your fox:outline creation template doesn't have an id, just don't create the fox:outline element. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: URLs in external-graphics - corrupt PDF
Psi Aushilfe3 wrote: --- Start -- I was trying to put an absolute http URL into an fo:external-graphics src attribute and got an corrupted PDF which Acrobat refuses to open. If I use an relative local file system path everything works just fine. Can't I use URLs?! .or what may I be doing wrong? --- End --- AFAIK, you should be able to use URLs. Check your syntax against: http://xml.apache.org/fop/fo.html#external-resources I can't tell from your report whether you tested the same image on a local file system as you tried using the URL. If not, be sure to try that, to try to eliminate the possibility that the image itself is causing the problem. Also, be sure to turn on the -d option for debugging, and look in the log. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Custom TT Fonts not embedded gives garbage
Victor Mote wrote: board. At the very least, in the short term, we need to improve the doc to reflect this -- I'll make understanding what is going on here documenting it a priority. OK, I have rewritten the doc to reflect what I *think* I know about this issue. See: http://xml.apache.org/fop/fonts.html#truetype-metrics where a list of command-line options for the readers has been added, with a table summarizing these differences in the -enc section. I would be very glad to have Ivan, Jeremias, and Joerg (and anyone else interested) review this for errors and omissions. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Special charecters into FOP
jb wrote: I've have a problem getting special charecters show correct in the PDF generated by FOP. To not make the XML import file corrupt i change all special chars to f.ex. char(38) = = #38; etc. i've also tried this char(38) = = #x0026; should equal the Adobe standard font. but the PDF just shows #x0026; what am i doing wrong here ? AFAICT, either of them should work. However, I am suspicious of the char(38). That looks like it is part of a program instead an XML document (but maybe you are just showing the decimal equivalent). If you are trying to encode the value in Java, use the hex value \u0026 or just the character in your string. BTW, there is also an amp; entity for this purpose. See http://xml.apache.org/fop/fo.html#xml-entity-chars for more details. Another possibility is that you are getting the character encoded in your semantic XML document correctly, but that it is being transformed incorrectly when you convert to XSL-FO. Check the XSL-FO document to see whether the problem occurs before or after that point: http://xml.apache.org/fop/running.html#check-input If it occurs before that point, then you really have an XSLT question. Otherwise, please make sure you are running the latest version of FOP, then post back to this list with a 2-3 line snippet showing the context (more if needed). Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: compliance for 0.20.4 or 0.20.5?
Robert P. J. Day wrote: just being pedantic, but if that compliance table is for the latest version of 0.20.5, the page title should be updated. Good point. I already fixed this in CVS earlier today when I was changing the other stuff. Putting the version on there seemed like a good idea at the time. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fonts?
Clay Leeds so that really is two). If so, please draft up a concise alternative and submit it. My criterion for committing the change will be whether it makes the page more or less understandable. I would agree. I'll take a bit of time to see if I can come up with something that makes sense, and if so, I'll send it in. If it makes more sense, I'll either submit a patch, or you can update it... I reworked the text in question a bit while I was messing with explaining the color-coding better yesterday. All of those changes are now on the live site, so please review the new text to see if you think further changes are required. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fonts?
Clay Leeds wrote: On Wednesday, July 23, 2003, at 10:55 PM, Victor Mote wrote: Robert P. J. Day wrote: so why do these table entries also say yes or no if the color is already supposed to indicate this? and what's with the entries with the single .? yes and no and partial indicate raw conformance. The location of those values is in the column related to their compliance level. The color coding is merely the merger of these two items in a visual manner, indicating the raw conformance with regard to the compliance level. So, for example, if object/property x is required for conformance at the Extended level, but is not implemented in FOP, it still shows up as blue in the Basic column, because it is not required there. Reds and grays in the Basic column indicate deficiencies for Basic conformance. Reds and grays in the Extended column indicate deficiencies for Extended conformance, etc. The periods are merely placeholders. And yes, I know about nbsp; but the last time I checked it didn't work with our web publishing workflow. Would it make sense to include this explanation on the compliance.html page? I'm going to ask you to answer your own question before I make a change. If you think it is unclear on the site now, or can be improved, then that makes two who think so, which in my mind is a quorum. (I will often makes changes based upon the suggestion of only one, but it is because I agree with them, so that really is two). If so, please draft up a concise alternative and submit it. My criterion for committing the change will be whether it makes the page more or less understandable. As for the frequent . perhaps a hyphen - would make more sense as a placeholder. In many tables I've seen, the - is used as a placeholder... Rather than canvass the world to find out which of ., -, *, ^, #, @, +, etc. if preferred, or building separate versions so that each can view their preferred character, I went ahead found the workflow problem, so that those table cells will be blank instead. That is probably also disagreeable to someone somewhere, but I don't care. It will be a few days before that shows up on the live site. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fonts?
Robert P. J. Day wrote: i understand the concept of a level of compliance of any feature being one of basic, extended or complete. so, as i read it, for any feature, it either is compliant for one of those three levels, or it isn't. if that's the case, there seems to be no need for anything but one of two colors, right? each table entry should represent simply yes or no. however, there are some partial compliance levels listed. what's the significance of partial? clearly, that would technically mean no, correct? so why is it important that someone know that a particular level is partially compliant? Yes, partial is a subset of no. This document has two very closely-related purposes. The first is to document the conformance to the standards. The second is to help users understand what they should expect when they use FOP. It is for the second purpose that partial is important. Yes, I could document all of them as no, but that would be a disservice to those who might benefit from knowing that it actually does the part that they need. on top of that, i see several na entries. i assume that means there is no such compliance level for that feature. fair enough. na means not applicable, which simply means that they don't apply to FOP, because they don't apply to any of FOP's output options. The text of the document explains it this way: Please note that a number of properties and categories of properties are not supported because they do not apply to documents in visual formats. I just committed a change that should make this more clear. so, in the worst case, you need four table entries: yes partial (if this is even necessary) no N/A Yep, that's what we have. at the risk of being north-american centric, why not just use the traffic light colors? green == yes yellow == partial (caution, warning, you get the idea) red == no If I can be convinced that people are somehow confused or offended by the existing arrangement, I'll think about changing it. Otherwise, I this line of discussion looks like a real time-waster. and perhaps white for N/A. given that the colors represent the N/A already is white. table entries, i see no need to have anything else in those table entries in terms of text. What else are you seeing? The four you list are the four that are there. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANNOUNCEMENT] FOP 0.20.5 released
Markus Schutz wrote: Something that I still miss (and maybe I'm not the only one) is support for properties like 'keep-with-next' or 'page-break-after=avoid'. When it comes to customer projects, lacking support for these properties is in most cases the knockout for FOP - users would not like to see a heading on the buttom of one page and the first paragraph on the top of the next page. Please note that is not always possible to use the blind table workaround! I know, it's not an easy task to implement, but would one of the FOP developpers like to tell me whether there is a timeline when these properties will be supported? This is pretty well documented here: http://xml.apache.org/fop/gethelp.html#compliance Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thai Hyphenation
Sherlane Lam wrote: It is very hard to find any distribution of hyphenation pattern for Thai. I can do hyphenation for Chinese, Japanese and some other Asian languages correctly with FOP even I have not used a specific hyphenation pattern. However, only Thai, I cannot do it correctly. Therefore, I want to find some hyphenation pattern in FOP site. However, I cannot find (or I don't understand) any information in both FOP and CTAN sites. Any suggestion/direction for me? As Joerg has already mentioned, they don't exist (in FOP anyway), and we don't really know enough to build them. However, we are in the process of beefing up the hyphenation documentation to include information about how to create/modify the patterns files. If you are interested in sorting through the linguistic issues, we'll do our best to support you on the technical side. If you can find an electronic Thai dictionary that includes hyphenation, that should be a big help. Do you have any interest in helping with this? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PDF spec
Howard, Karl wrote: For generating PDFs i'm looking at using either FOP or writing out the PDF using the PDF spec. In looking at the PDF spec, i've gone through the reference .pdf that adobe provides and am looking through other documentation on their site. But I'm trying to figure some stuff out that isn't explained as well as i'd hoped. Does anyone know of any books or sites that detail this well that they could recommend? No, but here is an idea that might help some: Download the FOP source code and learn from the PDF renderer. With the Adobe doc (theory) in one hand and the FOP source code (practice) in another, you can probably make good progress, and with the Apache license, you can even use FOP's work as the basis for your own (see the license for details, linked from the FOP home page). Of course, ideally we'd like to see you help us improve it along the way too :-) Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Questions about memory
Symon ([EMAIL PROTECTED]) wrote: So here's come the first stupid question : is there a way to make FOP swap on hard drive for big document generation (we don't care about the time it takes to generate our catalogs), if not, can you explain me why ? Do you know if XEP can swap on drive ? Not a stupid question at all. AFAIK, there is no way at the FOP level to force more swapping than occurs now. There might be things you can do at the OS level to increase the amount of virtual memory available. As for why, the short answer is that it is a non-trivial task to implement this intelligently. However, it is part of what is being addressed in the redesign: http://xml.apache.org/fop/design/index.html#pri-goal-unlimited-size I do not know whether XEP swaps. And here's my second question, if the first response is no, do you think we will be able to generate our monstruously big catalog if we add 2Go RAM on our server ? Short term, that is the right general solution (there isn't a good way of knowing whether you need 2GB or 200GB). Long term, it might make more sense to contribute developers or money to FOP development to get the redesign work done. We have a bunch of talented developers already working on the project that would love to work on it full-time. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PDF in Asian languages (Simplified Chinese,Traditional Chinese, Japanese,Korean)
Tom Chen wrote: To generate PDF correctly in Asian languages (Simplified Chinese,Traditional Chinese, Japanese,Korean), we have two choices: 1) Embedding the font in PDF. 2) Without embedding, using the asian language fonts provided by Adobe Acrobat Reader's Asian Font Packs (http://www.adobe.com/products/acrobat/acrrasianfontpack.html) For the first choice, the fatal disadvantage is there's font license problem for the PDF generator(i.e. the application vendor adopt FOP). Please clarify. You don't mean that there is a licensing problem with FOP, do you? Are you saying that you are not licensed to embed the fonts in your documents? If so, perhaps using different fonts would work. So I much prefer the secord choice. However, FOP doesn't seem to support the fonts in the Acrobat Reader's Asian Font Packs without embedding. I wonder if there's way to take the second choice using FOP? I think so, but I wouldn't be sure until the job is done and everything works properly. Using either the Asian Font Pack or the 6.0 Reader (which seems to have AFP built in according to the document you reference), try to find the applicable font files, and build metrics files for them, as per: http://xml.apache.org/fop/fonts.html I haven't looked, but the fonts are probably OpenType wrappers of Type 1 fonts, so it seems likely that neither our TTFReader or PFMReader will work, but I would try them anyway. If that works, please consider contributing the metrics files back to the project. If not, please post a message to this list to that effect. I also have a need to have OpenType font support, but haven't had time to explore it, so maybe this is a good time. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PDF in Asian languages (Simplified Chinese,Traditional Chinese, Japanese,Korean)
Eddie Cheng wrote: I am encountering the similar problem with you for generating Traditional Chinese pdf. I have generated the font metrics file from window mingliu.ttc font file. However, still many words from Supplementary Character Set (http://www.microsoft.com/hk/hkscs/default.asp) are missed. Moreover, it seems that true type extension (tte) font file are not supported. See http://xml.apache.org/fop/fo.html#xml-special-chars for the general answer. Specifically does the font contain the character you are trying to use? Follow instructions at above link to find out. Further, I would like to know whether fop support more than 1 font metrics in userconf ? If yes, how to specify? Yes. Just put them in. See the conf/userconfig.xml file for examples, or look here at the CVS code: http://cvs.apache.org/viewcvs.cgi/xml-fop/conf/Attic/userconfig.xml?rev=HEAD only_with_tag=fop-0_20_2-maintaincontent-type=text/vnd.viewcvs-markup (you'll probably need to cut-and-paste that URL) Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: using userconfig.xml
Clay Leeds wrote (a long time ago, May 14, 2003 to be exact): Well, to answer my own question (how else can userconfig.xml be modified...), it appears that SVG can be modified (from the FOP/Graphics page): ... BTW, I don't know what other options there are for modifying userconfig.xml for improved/customized FOP output, but it looks like this SVG entry might be better suited for display on the FOP/Configuration page (http://xml.apache.org/fop/configuration.html) (with a link from the FOP/Graphics.html#svg section: http://xml.apache.org/fop/configuration.html I guess the age old, should SVG-specific configuration information be placed on the Configuration.html page (with a link to configuration.html#svg), or on the Graphics page? The same would hold true for FONTs... First, I apologize for being so slow. I have now done (in CVS) most of what you have suggested here. Specifically, the configuration documentation now shows all of the configuration options, with detail where necessary (we can always add more later), and cross-references for items that are addressed in other parts of the doc (like fonts, and now, hyphenation). NOTE to Victor/DEV: although the information is in conf/userconfig.xml, we might want to add an example XML entry showing how to add a hyphenation pattern directory. Here's example copy: To add the hyphenation directory (filled with all sorts of hyphenation patterns such as the Klingon Hyphenation pattern) located at /java/fop-0.20.4/hyph/, enter the following in the HYPHENATION section of userconfig.xml: entry keyhyphenation-dir/key value/java/fop-0.20.4/hyph/value /entry What I have done with this is to show in a general way how to set the key-value items in the configuration. Since they are all the same, it doesn't seem to make sense to document all of them. Look for these changes to be on the live site sometime in the next 24 hours. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: using userconfig.xml
Clay Leeds wrote: What I have done with this is to show in a general way how to set the key-value items in the configuration. Since they are all the same, it doesn't seem to make sense to document all of them. Fine with me, although since there're only 3 or 4 different possibilities (I don't recall if there are others), it makes sense (to me) to provide an example of each. True for the moment, probably not true for long. FWIW, the keys I am aware of are: baseDir, fontBaseDir, hyphenation-dir (shouldn't that be 'hyphenationDir', 'hyphDir' or 'hyphBaseDir'?). The Probably. That's probably not going to get changed in the maintenance branch, but will probably get fixed in the normal course of things with the API changes coming in the trunk. fact that the latter is non-standard makes me think it would be better to provide an example for each. In my view, the best way to minimize the posting of FAQs to the list is to 'idiot-proof' (as much as possible) the userconfig.xml file itself, by giving as many examples as relevant. Practicing brevity in 'help' files may be counter-productive. I *think* the way it is set up now will work fine. Part of what I am trying to highlight is the massive *similarities* between the key-value entries, which ought to reduce errors on another axis. I may be wrong. If so, we'll change it later. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another website update
Ben Galbraith wrote: I changed FOP to check a different region of the file for the text Adobe Photoshop, which does indeed confirm that Photoshop generated the file. Can you facilitate that patch being applied, if such falls within your responsibilities? Yes, I'll be glad to do that. Right now, we have a code freeze pending the upcoming 0.20.5 release, but I will work on getting it applied after the release. If you can, would you also add two attachments to the bug, one being a Photoshop-generated image, and the other being generated by another application, that will illustrate the problem and the solution? Smaller is better as long as the effect is clear. Please identify the generating application in both cases. Thanks, and thanks again for your efforts here. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another website update
Ben Galbraith wrote: Sun's new Java Advanced Imaging I/O Tools 1.0-RC plug-in writes CMYK JPGs in such a way that FOP believes the CMYK sample values are inverted when they are not. This leads to CMYK JPGs looking really, really bad. Is this a problem from JAI's side or from FOP's side? IOW, should FOP be able to tell from the file itself whether to invert or not? Or is Sun writing the image wrong? Or is this a limitation in the JPG format? When I force FOP to interpret the CMYK JPG as not inverted (by modifying the source code), they work as they should. Can we document this issue on the website for posterity? Yes, but I want to understand the issue better first. A likely fix would be to add a configuration option to FOP that forces JPGs to either be inverted or not inverted, regardless of what FOP thinks it should do? The code that presently determines whether or not to invert (JpegImage.java [fop-0_20_2-maintain] 1.1.2.3, 214-215; see also 172-182) is rather approximate. Depending on the answer to my question above, is it possible to make FOP's logic more definite? I would lean more toward such a solution, if it is feasible, than toward a configuration option that would force one result or another for all images in the document. I'd be happy to contribute such a patch, if there is interest from the community / developers. Excellent. Do you have any interest in helping us track down the more robust solution (if it exists)? Thanks again for your efforts here. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: difference between pdf and ps
Todtenhaupt, Susann wrote: I've implemented a stylesheet to produce pdf and ps. So far so good. There are several tables (with some columns)in it. The pdf looks as wanted, but in the ps-file, some columns are ignored and the text isn't subordinated these columns. Also, whitespaces are not regarded. What is my mistake? The short answer is that the PostScript renderer is not as mature as the PDF renderer: http://xml.apache.org/fop/output.html#ps Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Website update?
Ben Galbraith wrote: So the final text could probably be reduced to: FOP's native support for TIFF's is limited to single channel images (i.e., bi-level and grayscale). Said images must use CCITT T.4, CCITT T.6, or JPEG compression, and must use white-is-zero encoding (TIFF's 'photometric interpretation' field). Got it. Thanks. As I am writing this up, I wonder whether the FOP native support handles uncompressed images as well? Do you know? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another website update
Ben Galbraith wrote: I think it is possible to patch FOP to properly detect whether or not to invert the image from the APPE marker values, rather than the presence of the marker. I'm not sure how to do it, yet. I 'spose I should figure it out! Excellent. Do you have any interest in helping us track down the more robust solution (if it exists)? Sure, I'll start tracking it down in my spare time. That is greatly appreciated. It sounds like you have a sizeable head-start (over me anyway) on the details, and my guess is that without your efforts it will be awhile before any of the developers would be able to do much on this. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PNG doesn't show in a pdf
Bonnie Yelverton wrote: I was wondering about jimi, which is art of the recommended code line for XSelerator. I have now installed it, but the png didn't show up. Maybe I have to restart my computer? You shouldn't need to do that. Did you get any errors? Also, have you built FOP on your local machine, or are you using downloaded binaries? If you have built it locally, you will need the jimi and jai files installed in the correct directories at build time so that support for them will be included in the compile. I also downloaded jai, but the files the FOP instructions said I should sopy over to the FOP/lib folder weren't part of the download. (Please excuse my ignorance about Java. I've only had a very basic beginner course.) Look in the lib directory. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PNG doesn't show in a pdf
Bonnie Yelverton wrote: I'm using the downloaded binary, which did not include jimi, jai or logkit in lib. Is that an error? No, that is fine. I just wanted to make sure you didn't build fop without them in place, because that will prevent their use at runtime, even if they are there are runtime. I have now added the jimi and jai files. Unfortunately the programs I'm I am confused by now. Were they in place before (when you said the PNG wasn't being rendered)? If you are still not getting output, and getting no relevant error messages in your log, then please do a dir or ls on your lib directory, and paste the results into your return message. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PNG doesn't show in a pdf
Bonnie Yelverton wrote: I just created my very first pdf from an FO, thanks to help I've received here. But to my dismay, one of the graphics, which happens to be in .png format, doesn't show in the pdf. I haven't had problems with pngs in pdf before. Does anyone have an explanation - or a reference I can study? Bonnie Have you looked at: http://xml.apache.org/fop/graphics.html ? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: show page number with current-page-no / total-page-no (ie, 3/10)
Zahidul Islam wrote: Start i want to show the page number in all the pages at the footer. for showing current page number i used fo:page-number/. but i want to show the page number in the given format ( current-page-no / total-page-no (ie, 3/10) ). how can i do that. pls help me. End See: http://xml.apache.org/fop/fo.html#fo-total-pages Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: checkbox in pdf
Zmitko, Jan wrote: thanks, this is that i need. I´ve tried it with image, but i need some checkboxes and i think it´s not so perfermant and so i´ll choose the way with unicode. The following document (available from the Examples menu item on the FOP web site) shows the glyphs available in the base-14 fonts, and their equivalent code-points: http://xml.apache.org/fop/fo/fonts.fo.pdf Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AWTRenderer thread safe?
Reto wrote: I have investigated this and have done some multithreaded tests with AWTRenderer a few months ago. The conclusions can be found in the archives of this list. Summary: - AWTRenderer and all subclasses of it (TIFFRenderer...) are NOT threadsave. - It is not threadsave because the underlaying AWT libs are not threadsave. It does not help to use different instances of REnderer, Driver , or anything else. You need different VMs to run AWTRenderer concurrently. - There is no simple way to adjust AWTRenderer to be threadsave. It probabaly needs a complete redesign - I don't think it is even possible to make an AWTRenderer threadsave, since it would have to be written without using AWT. Yes, your comments are the ones that I referenced in my answer, and they were very helpful. The only thing that troubles me is that although it is well-documented that Swing classes are not thread-safe, I can find nothing similar for AWT, so I am hesitant to list that as the cause. For now, I have documented that the AWT Renderer should not be multi-threaded, but have not documented why. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AWTRenderer thread safe?
J.Pietschmann wrote: Victor Mote wrote: My suggestion then would be to download 0.20.5 see whether it fixes your problem. I think it will, I don't think so. The issue with randomly changing font families and font weights in the AWT renderer has been reported before, and I vaguely remember this was deemed a problem with JDK 1.4. Searching the mailing list archives may turn it up. Maybe upgrading to 1.4.1_03 is of some help... OK, a look at the archives indicates that AWT probably is the issue. Here is the most relevant posting I could find: http://marc.theaimsgroup.com/?l=fop-userm=104506926016789w=2 I have not been able to confirm any expected thread problems with AWT classes, so there may be something else going on here. I'll add a comment to the doc regarding this. Also, I didn't find anything about a 1.3/1.4 difference, so if anyone knows what that is about, or can shed more light on why or when, I'll be glad to clarify the doc. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AWTRenderer thread safe?
Valeiko, Michael wrote: I am creating a new Driver per thread, as well as a new renderer. Does setting a new renderer fall under the do not change the configuration data while there is a Driver object rendering ? I don't think so. However, your symptoms sure sound like static data being ping-ponged around between threads. It is not static in Driver.java. PS - going to 20.5 is not really an option since we are close to releasing and who knows what will break. My suggestion then would be to download 0.20.5 see whether it fixes your problem. I think it will, but if not, we probably need to make some changes to the doc. If it does fix your problem, then your choices (using FOP) are 1) upgrade, 2) do without multithreading, 3) live with it the way it is, 4) find the changes in the source tree that affect multithreading merge them into 0.20.4 (probably more risky than the upgrade). I wish I had a better answer. We're working on improvements to this in the redesign code. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AWTRenderer thread safe?
Valeiko, Michael wrote: Start I am experiencing a weird inconsistent bug and was wondering if it is related to the AWTRenderer. I have embedded fop into a web based app. the can receive multiple print request on separate threads. The printed output sometimes has inconsistent formatting ( wrong font or weight ) randomly. I can print the same documents again and they will print fine. The fo documents appear correct, so I'm wondering if it can be thread related in some of the fop classes. I've never had the problem printing a single document. I am using 20.4 and jdk1.4.1_02 End This is actually an FAQ: http://xml.apache.org/fop/faq.html#multithreaded Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: lining up amounts w/ and w/o parentheses
Partridge, Michael wrote: My pdf is a bill which lists positive and negative amounts in a table, and I need to use parentheses for the negative amounts. The problem is that those w/ parentheses don't line up with the others - they're pushed left (because everything is right-aligned). I've tried this: What you really want here is to align on the decimal point, but according to http://xml.apache.org/fop/compliance.html#fo-property-text-align text-align=string is not yet supported. The best workaround that I can think of is to put your trailing ending parentheses into a separate table cell, which is aligned /left/. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: testing support for various graphics formats
The web site published minutes ago reflects changes to the graphics documentation that resulted from this and the related threads. Many thanks to Robert P. J. Day for his persistence in bringing the needed changes to light. The substance of his efforts here was outstanding, and he has made a valuable contribution to the project. Many thanks also to Jeremias Maerki for actually developing the answers. There may very well still be errors or omissions. If so, please raise them in this forum, and we'll work on getting them fixed. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Help with JAI, TIFF, and FOP
Victor Mote wrote: J.Pietschmann wrote: Contrary to the documentation, JAI support in 0.20.4 requires nontrivial code changes. Simply dropping in the JAI API jar isn't sufficient. I still don't have time to look at the code today. Do you think this comment was intended to document the redesign branch instead of the maintenance branch? OK, now I understand this to be distinguishing between 0.20.4 and the 0.20.5 release candidates. I will open a thread on fop-dev to discuss synchronization of the web site with our releases. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ok, now it's JIMI time
embarrassing myself. i'm trying *really* hard to point out deficiencies in the docs so that others after me don't have to go throught what i went through. and your attitude i can really live without. What you are asking us to do is to place a sign in the windshield of the car saying do not drive this car off the cliff. That might be useful, but it would also obscure the vision of the driver which can cause a lot of other problems. What you have no way of knowing is that a few weeks ago, the graphics doc for bitmap formats was almost non-existent. IMO, it is much better today than it was then. Your comments will likely help make it better. However, the path was unnecessarily bloody and painful. FOP is an open source project. If it doesn't work that way it should, it is just as much your fault as it is mine or Joerg's. I recommend taking a more constructive approach. At some point it becomes a disservice to other FOP users to spend time dealing with threads like this. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ok, now it's JIMI time
Robert P. J. Day wrote: Only if you follow the instructions everywhere else. You still have a problem either in your build or in your runtime environment. I frankly will not take the time to help you find it. in the first place, the major problem here is that those instructions are, in some critical cases, misleading or just plain missing. In no material respect is this true, at least after the patches that have already been made to CVS and provided to you through this mailing list. more to the point, as you may recall, one of your earlier pieces of advice was to not run FOP directly, but to invoke it through fop.sh, which turned out to make no difference whatever and was a script you turned out not to fully understand anyway. Well, here is the very first response to your graphics questions: http://marc.theaimsgroup.com/?l=fop-userm=105254830813143w=2 in which I state: So, you can hack fop.sh if you wish, but if you do, then make sure you hack build.xml as well, because otherwise if you try to build FOP from source down the road, you will do so without JIMI or JAI support. Based on the subsequent history, your next response should be Oops. I have already done that. Then we move forward to get it built properly. Instead what we got was: http://marc.theaimsgroup.com/?l=fop-userm=105256848322848w=2 a rant about how cumbersome and awkward it was for FOP to require installation in a specific spot. As for my advice about fop.sh, a standard practice when debugging a problem similar to yours is to isolate the differences between an environment that works and one that doesn't. So I stand by my advice to go back to stuff that we know works until we find the piece that caused the problem. I know fop.sh well enough, but am and should be embarrassed for my misreadings of how the CLASSPATH was being built. In fairness to myself I must point out that if there is nothing wrong with the compile-time environment, then I must look for something in the runtime environment that explains the fact that your system doesn't work when so many others do. The only other parts of your posting that require a response from me: any time you want some help improving the documentation, let me know. i've written a *lot* of documentation and courseware in my time, and i'm pretty good at it. We're glad for any help that you can offer. Just understand that this is *really* cumbersome and awkward is not nearly as helpful as a patch to the code and/or doc that makes it less cumbersome and awkward. but i have no interest in writing anything along the lines of, just do it this way and don't ask questions. FOP user doc is written for a general audience. I don't care whether they just do it this way and don't ask questions or whether they know what they are doing and proceed from there. You cannot be persuaded to join either group. I humbly and sincerely beg forgiveness from this group for my participation in these threads. I regret all of it. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: graphics, PNG files, JIMI and JAI
Robert P. J. Day wrote:
in my simple docbook document, i've added a couple figures,
one with a JPG file (renders nicely), one with a PNG file (does
not render at all). both show up in the .fo file as a
fo:external-graphic, so i know *that* part of it is correct.
from what i read in the FOP FAQ, PNG support is provided by
either JIMI or JAI. in fact, i have both installed and their
jar files on my java CLASSPATH.
the FAQ graphics entry for JIMI is a bit confusing, since
it suggests that i should install the JimiProClasses.zip file
(actually, i'm using the jar file) in the directory
xml-fop/lib/jimi-1.0.jar. why is it not sufficient to put
the Jimi jar file on my CLASSPATH?
If you are using a home-grown script that is fine. However, I suspect that
you are actually using fop.bat or fop.sh at some point. If so, then a
cursory examination of those scripts will show that FOP doesn't use your
classpath at all, but builds its own. This is important for some of the
dependencies (like Batik) that require a very specific version number to
work correctly with FOP. So, you can hack fop.sh if you wish, but if you do,
then make sure you hack build.xml as well, because otherwise if you try to
build FOP from source down the road, you will do so without JIMI or JAI
support. IMO, it is really much better to simply follow the instructions.
and what's with the xml-fop directory? where is *that*
supposed to be?
I'll take the blame for that one. That should read {fop-install-dir}
instead. The xml-fop directory is the location in CVS, but it could be
installed anywhere on your system. I have fixed the doc for this in CVS (it
will be a few days before it shows up on the live site).
again, both the jimi and jai jar files are
on my classpath. shouldn't that be sufficient?
Same story on JAI. Here is the revised (source) documentation for JIMI
JAI:
section id=jimi
titleJIMI/title
p
Because of licensing issues, the JIMI image library is not
included in the FOP distribution. First, fork
href=http://java.sun.com/products/jimi;download/fork and install it.
Then, copy the file JimiProClasses.zip from the archive to
{fop-install-dir}/lib/jimi-1.0.jar. Please note that FOP binary
distributions are compiled with JIMI support, so there is no need for you to
build FOP to add the support. If jimi-1.0.jar is installed in the right
place, it will automatically be used by FOP, otherwise it will not.
/p
/section
section id=jai
titleJAI/title
p
FOP has been compiled with JAI support, but JAI is not included in
the FOP distribution.
To use it, install link
href=http://java.sun.com/products/java-media/jai;JAI/link, then copy the
jai_core.jar file to {fop-install-dir}/lib.
JAI is much faster than JIMI, but is not available for all platforms. See
link
href=http://java.sun.com/products/java-media/jai/forDevelopers/jaifaq.html#
platformsWhat platforms are supported?/link on the JAI FAQ page for more
details.
/p
/section
in addition, my FOP output contains:
... snip ...
[INFO] [10]
[INFO] Failed to load JAI, using Jimi instead
[ERROR] Error while creating area : Error creating FopImage
object (Error creating FopImage object
(file:stylesheet-images/tip.png) : org.apache.fop.image.JimiImage
[ERROR] Error while creating area : Error creating FopImage
object (Error creating FopImage object
(file:stylesheet-images/note.png) : org.apache.fop.image.JimiImage
[ERROR] Error while creating area : Error creating FopImage
object (Error creating FopImage object
(file:stylesheet-images/important.png) : org.apache.fop.image.JimiImage
[ERROR] Error while creating area : Error creating FopImage
object (Error creating FopImage object
(file:stylesheet-images/caution.png) : org.apache.fop.image.JimiImage
[ERROR] Error while creating area : Error creating FopImage
object (Error creating FopImage object
(file:stylesheet-images/warning.png) : org.apache.fop.image.JimiImage
... more snip ...
[ERROR] Error while creating area : Error creating FopImage
object (Error creating FopImage object (file:cover.png) :
org.apache.fop.image.JimiImage
[WARNING] Some static content could not fit in the area.
[WARNING] Some static content could not fit in the area.
[INFO] Parsing of document complete, stopping renderer
rm -rf ./stylesheet-images
cp -a `xmlcatalog /etc/xml/catalog
http://docbook.sourceforge.net/release/xsl/current | sed -e
's,^file://,,'`/images ./stylesheet-images
Let's see how much of this is cleaned up when you let FOP find the classes
it needs.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do you configure FOP to use JAI?
Steve Albin wrote:
---start---
The FOP documentation says in order to use JAI simply install it. I did but
FOP doesn't appear to use it. I get the following error when trying to
generating a PDF with a PNG graphic:
[ERROR] Error while creating area : Error creating FopImage object
(file:/C:/image.png) : Jimi image library
not available
---end---
It looks like our doc is a bit deficient. I just upgraded the CVS version to
the following (it will take a few days before this shows up on the live
site):
section id=jai
titleJAI/title
p
FOP has been compiled with JAI support, but JAI is not included in
the FOP distribution.
To use it, install link
href=http://java.sun.com/products/java-media/jai;JAI/link, then copy the
jai_core.jar file to {fop-install-dir}/lib.
JAI is much faster than JIMI, but is not available for all platforms. See
link
href=http://java.sun.com/products/java-media/jai/forDevelopers/jaifaq.html#
platformsWhat platforms are supported?/link on the JAI FAQ page for more
details.
/p
/section
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: graphics, PNG files, JIMI and JAI
Robert P. J. Day wrote: If you are using a home-grown script that is fine. However, I suspect that you are actually using fop.bat or fop.sh at some point. in fact, i'm using neither fop.sh nor fop.bat. given the number of java tools i'm using (xerces, xalan, saxon, etc.), i have a single directory where i keep all those jar files, and my CLASSPATH contains all of the relevant jar files. so far, it's worked fine, until i got to FOP. OK, so go back to my first statement: If you are using a home-grown script that is fine. So, if you're smart enough to write your own script, then we can at least hope that you are smart enough to debug one. Use whatever method you like. IMO, the easiest way to do that in this situation is to first do it the way that works for thousands of other people, then systematically figure out what is different between that approach and the approach you are trying to use. It frankly seems abusive to say I understand the instructions, but refuse to follow them, and insist that someone help me design an approach that suits me better. There are people who can do that for a fee (FOP developers among them), but I don't feel any obligation to customize your installation for you for free. If so, then a cursory examination of those scripts will show that FOP doesn't use your classpath at all, but builds its own. This is important for some of the dependencies (like Batik) that require a very specific version number to work correctly with FOP. So, you can hack fop.sh if you wish, but if you do, then make sure you hack build.xml as well, because otherwise if you try to build FOP from source down the road, you will do so without JIMI or JAI support. IMO, it is really much better to simply follow the instructions. while i can appreciate the version dependency issue, this strikes me as a *really* cumbersome and awkward approach. i took at look at fop.sh, and from what i can see after first pass, there should be no difference between installing JIMI/JAI under the fop directory, or copying their respective jar files wherever i want, as long as the CLASSPATH is set correctly. Well, it may be cumbersome and awkward, but usually we ignore such comments unless they are accompanied by a suggestion for improvement. I see none. Nevertheless, I agree in principle with your conclusion that it should run if you are properly setting your CLASSPATH to point to it. forcing either JAI or JIMI to be installed under the fop directory for proper operation is, IMHO, a bad thing. but perhaps i've just missed some final step that will make it work. i'll give it another shot. Well, nobody is forcing you to do that. We don't even force you to install the FOP stuff in the FOP directory. You can extract class files spread them out all over tarnation if you wish. We have no way of preventing it and no desire to do so. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: clarifications about using JAI/JIMI with FOP
Robert P. J. Day wrote: 4) when i try to transform my .fo to .pdf, eventually i get the message: [INFO] Failed to load JAI, using Jimi instead what does this mean? does it mean that FOP simply couldn't find the JAI jar files, or that it found them but, perhaps because of a misconfiguration on my part, couldn't load the appropriate classes? it's pretty crucial to know which of those errors is being identified here. I don't have time to look at the code right now, but I am 99% sure it means that it could not find the JAI jar files. AFAIK, there is no other configuration required to run JAI. Victor Mote Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: graphics, PNG files, JIMI and JAI
Robert P. J. Day wrote:
Then, copy the file JimiProClasses.zip from the archive to
{fop-install-dir}/lib/jimi-1.0.jar. Please note that FOP binary
um ... i don't understand the idea of copying a .zip file to
a new location, and renaming it to be a .jar file.
cp tmp/xyz.zip xml-fop/lib/abc.jar
I'm not sure how this evolved, but I think the purpose for it must be so
that the hard-coded build system can find them in the proper place. AFAIK,
there is no problem with letting your CLASSPATH point to them in a different
place if you are running but not building FOP. I could be wrong, which is
why I think you need to isolate the difference between your approach and
the standard approach.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: graphics, PNG files, JIMI and JAI
Robert P. J. Day wrote:
i have, in fact, been testing this all morning. despite the fact that i
don't see how invoking FOP through fop.sh can make any logistical
difference, i did copy the jai_core.jar file under the {fop}/lib
directory, i used fop.sh, i verified that all .jar files under that
directory are being prepended to the classpath that is used by the
eventual call to FOP.
so far, no go. now, it may well be that i'm still doing something
wrong, but frankly, it should *not* be this hard. despite my adding
both JIMI and JAI to my classpaths, and copying them under {fop}/lib,
neither of those libraries are managing to render a simple .png
file.
i'm open to any suggestions as to how to isolate the problem here.
OK, you have me convinced that we might have a FOP problem here. Let's start
by copying the other JAI files into the {fop-install-dir}/lib directory to
see if that makes a difference.
Also, I have to leave shortly won't be back until probably Monday. So if
you don't get a response right away, please hang in there until either I get
back or someone else can pick up the thread.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: graphics, PNG files, JIMI and JAI
Robert P. J. Day wrote: it would make no difference since, if you take a close look at the loop in fop.sh, the fop/lib jar files are being *prepended* anyway. the end result would be the same. You are right again. I'll get a cup of coffee before I try to help further :-) Sorry for the noise. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: clarifications about using JAI/JIMI with FOP
Jeremias Maerki wrote: 2) i downloaded the latest JAI tarball from sun, and all it contains is three .jar files, and a shared library. following my standard practice, i copied those jar files to a standard jarfile directory i maintain, and added all of them to my CLASSPATH. (i realize that the usage instructions suggest copying those files under fop/lib, but it's not clear to me *why* that would make a difference, given what i read in fop.sh) The only files you need from JAI are: - jai_core.jar - jai_codec.jar I will add the requirement for jai_codec.jar to the doc. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: clarifications about using JAI/JIMI with FOP
Jeremias Maerki wrote: Copying them to fop/lib is important because you have to make sure FOP is compiled using JAI support. If you compile FOP yourself (means: you don't use the binary distribution) you have to put the two files above in fop/lib so the Ant build process installs JAI support in the first place. If you don't do that you get the error message in 4). The error message is misleading, however. So I changed it in CVS. FOP 0.20.5 will have a better error message. A comment concerning the CLASSPATH environment variable: Due to bad experiences in the past, many Java developers discourage the use of the CLASSPATH variable. Always using -cp is much safer as soon as you have more than one Java application on your workstation. On my machine, for example, the CLASSPATH variable is non-existent. So my 99% sure comment was in error. Just to be clear, the fundamental problem that Robert needs to address is that it would appear that he has done a local build without JAI support (as discussed in the related thread). If so, he should first rebuild FOP, preferably following the instructions, or alternatively by modifying the build.xml file to include the JAI jar files into the build. Any changes to the CLASSPATH or -cp are of secondary importance, and will not fix that fundamental problem (although Jeremias's advice sounds like best practice to me). Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PDF metadata
Clay Leeds wrote: I've read the chapter 9.2.1 (PDF spec) Document Information Dictionary and still don't know how to leverage this piece of information. Must I use Java to add this meta-data to the PDF file, or can I do it from the command line interface? In other words, can it be done from within xsl-fo? What do the calls look like? I think the best way to do this would be with our FO extension mechanism, using the fox namespace. There are no calls to do this right now, but it will be pretty doable after we get the redesign done. (Its actually pretty doable now, but the redesign needs to take priority). Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiple page-sequences per pdf page
Partridge, Michael wrote: This should be pretty simple, but I don't have my books with me. I need to get multiple 3.25in payment 'coupons' per page, and I'm not sure of the best approach. I know I could do it with one page-master and page-sequence and just pile them on top of each other, but they're identical except for content like date range, amount, and item(s). Each coupon will be matched to a coupon element in my source XML. Can anyone point me to a good example or description? Thanks! Trying to place multiple page-sequences on one page is a no-starter. Your other idea is better. The fact that the content is mostly identical doesn't make a difference one way or the other. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
