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: in XSLFO
Gang Li wrote: > Anybody know how can I get a line break like 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, 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: 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: > 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: 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: Column-balancing
Puppala, Kumar wrote: > I am trying to fix the column balancing issue in fop 0.20.5 > in my local copy. The method I am looking at is > resetSpanArea() in BodyAreaContainer.java. There is a fixed > value that we are adding in this function, which is referred > to as heuristic safety factor. The current value used is > (2*15600). Changing this value is having both positive and > negative effects on the layout. Does anyone know what this > value is supposed to accomplish? Maybe knowing more about > this might help me fixing my column balancing issue. I'm guessing that nobody knows that answer to your question. I don't know either, but my guess is that the author was trying to leave room for variations in line height that might exist, and to deal with rounding. The author noted that the algorithm is "primitive". IMO the algorithm needs to be totally rewritten. To do better, you will need to look at the height of each line and test "breaks" that minimize the variation in columns heights. BTW, AFAIK, FOP developers are no longer applying patches to 0.20.5 for any reason, which means that you will be maintaining custom code on your own. You may get a better return on your investment by working on one of the rewrite efforts. The FOP redesign is one, and the others are graciously listed by FOP here: 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: 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: 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: > > [...]UnknownEncoding[...]. 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: 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?
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: 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: 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: > 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: 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: problem with 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 . The > new lines does not appear in the PDF. > Any one has any idea abt it ? Please reply. There is no element in the fo: namespace. IIRC, you can accomplish the same thing with an empty element: Text on first line.Text on second line. 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. 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: 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: 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:
stream-filter-list
filter-keyword
The filter keywords are: flate, ascii-85, and ascii-hex.
To apply multiple filters, list them in the order they should be applied:
stream-filter-list
ascii-85
flate
To apply *no* filters:
stream-filter-list
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: > 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: 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: > "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.16&only_with_tag=MAIN&view=markup at line 240. 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: > > > > > 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: FOP ~ PropertyList search gives linear performance
Peter B. West wrote: > Property processing is a bit of a quagmire. I have just had a look at > the alt.design documentation, thinking I had detailed the data > structures in more detail than is actually the case. Some of the code > examples are broken at the moment, but the basis of the design for > parsing and representing properties is detailed there. > > The approach I took was to resolve all of the properties at every node > in the tree during the parsing. As the FO tree builder descends to the > leaf nodes, a complete properties array is maintained at each level. > Before the tree builder exits a node though, all properties not relevant > to that particular node type are discarded (i.e. the property sets are > "reduced") so that the maximal data arrays are short-lived. The > relevant properties are maintained in sparse arrays. > > There is a flaw in this approach which is exposed when markers are > processed. Because marker subtrees are conceptually "re-parented" in > the static-content tree of the page on which they are laid out, the > properties within the marker tree cannot initially be resolved, and the > properties of the static-content trees cannot be "reduced". This > situation is not catered for in the existing code, but is quite easy to > accommodate by not reducing the property sets of nodes in the > static-content, and by slicing the marker subtrees out and storing them > unresolved for later processing, including property resolution, in the > context of static-content. > > All of this assumes that property resolution cannot be completed > independently of layout. This is a major point of difference between me > and everyone else on the FOP team, but the implication is there in the > Rec. if you read it carefully. Peter: I'm going to move this over to fop-dev & respond there. 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:\FOP>fop -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: Rendering a Tiff image
Jeremy Nix wrote: > Is there currently a way of rendering a tiff image? If not, does anyone Not from FOP. > recommend a product for converting a pdf document into a tiff image? I use a printer driver from Lead Technologies called ePrint that works well: http://www.leadtools.com/utilities/printerdriver/eprint_printer_driver.htm 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: 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: 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: > 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
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: > 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: 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: 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 > > > > > > > > > > > > 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 > > > > 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: Error when placing svg into xsl with
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: > > > > 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: 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: 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 > > > 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: Can't install my font!
Chris Bowditch wrote: > Your userconfig.xml looks okay to me. The error you are getting > would imply > that FOP did not find the config file at conf/userconfig.xml. AWT > may or may > not be a problem, but I know for certain that custom fonts work > with PDF, so > my advice would be to get it working with PDF before trying AWT. I believe that AWT is the problem. See: http://xml.apache.org/fop/fonts.html#intro where it is documented that the AWT renderer does not use custom fonts. This is because AWT gets all of its font information from the operating system registration. If it isn't registered with the o/s, AWT (and therefore FOP) can't see it. O'Reilly has some good books on X if you don't have something else already. 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)?
>
> select="ReportData/Record/structItemRecord/core/structItem/strItem
> Number"/>
>
> select="concat('http://www.javabarcoding.com/servlet/lin?BARCODE=',
> $itemNumber,
> '&BAR_HEIGHT=1&CODE_TYPE=CODE39&X=0.03&CHECK_CHAR=
N&CHECK_CHARINTEXT=N&CODE128_SET=0>
&HEIGHT=100&WIDTH=400')"/>
>
> src="url()"/>
I'm not sure I'm following your question. Are you trying to do this?:
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: fox:destination
Julian Reschke wrote: > here's a very short description for "extensions.xml": OK, I have added this to CVS, along with a few embellishments. It should be live on the site within a few days. Again, thanks for pointing this out and helping to get it documented. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: fox:destination
Julian Reschke wrote: > while browsing the source of the maintenance branch I found out that FOP > already has support for creating anchors within PDF files (things that can > be addressed using URL fragment identifiers). It seems that?it works just > fine. > > Why is this missing from the documentation? If you are saying that there is a fox:destination extension that creates named destinations in a PDF, then the reason that *I* haven't documented it is that I didn't know about it. However, there is, IMO, another problem here, and that is that I don't think that should be an extension, but should work off of the "id" attribute. Right now "id"s can be targets, but AFAIK they don't create named destinations. I can't think of a good reason why targets shouldn't be named destinations, so that two birds are killed with one stone. I suppose there might be some file size advantage in some situations, so maybe it should be configurable. I suppose that any changes will need to be in the redesign, and that we should just document the existing behavior for now. At any rate, if you'll write something up and post it, I'll test it and get it into the doc. Thanks for pointing this out. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache FOP 1.0 release
srinivasan krishnamurthy wrote: > Do we know when the Apache FOP 1.0 version is going to > be released. No. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: bookmark extensions problems
Clay Leeds wrote: > That is correct. The fox: elements do not appear in the intermediate > .fo file I generated with xalan. That means it is not a FOP question, but an XSLT question instead. If you'll send me some XML/XSLT snippets offline, I'll help if I can, but I can't do that on this list. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant Task
Victor Mote wrote: > I'll bet it doesn't like those backslashes in your pathelement locations > (actually, it doesn't care, but it isn't doing what you want it to). Ant, > like Java, is filesystem-agnostic, and doesn't care which filesystem > convention you use to specify paths, but it does need for the backslash to > be escaped if you're going to use it. So, on all three, change the "\" to > "\\" or, if you prefer, to "/". If that doesn't solve the problem, then > build the entire path name in a variable, and use the Ant "echo" task to > spit what it is actually using. I may have spoken too quickly. My Linux system doesn't seem to care whether it is "/", "\", or "\\". So follow the last sentence above to debug this. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant Task
Lopez, William wrote:
> I'm attempting to use the anttask supplied in fop.jar...I have used the
> example from the docs to come up with a taskdef and task like so:
>classname="org.apache.fop.tools.anttasks.Fop">
>
>
> location="${dir.fop}\avalon-framework-cvs-20020806.jar"/>
>
>
>
>
>
> fofile="${dir.fop.fo}\${fo_filename}-${date}.fo"
> outfile="${dir.fop.output}\${fo_filename}-${date}.pdf" />
>
>
> ...but I get the following build error:
> BUILD FAILED
> file:E:/CM/Projects/NEW_BUILD_PROCESS/EDS_Build/Integration/fop/do
> cGen.xml:2
> 0: taskdef class org.apache.fop.tools.anttasks.Fop cannot be found
>
> The jars are in the directories as specified above. Developing
> environment:
> WinXP, j2se 1.4.2, Ant 1.5.3, FOP 0.20.5.
I'll bet it doesn't like those backslashes in your pathelement locations
(actually, it doesn't care, but it isn't doing what you want it to). Ant,
like Java, is filesystem-agnostic, and doesn't care which filesystem
convention you use to specify paths, but it does need for the backslash to
be escaped if you're going to use it. So, on all three, change the "\" to
"\\" or, if you prefer, to "/". If that doesn't solve the problem, then
build the entire path name in a variable, and use the Ant "echo" task to
spit what it is actually using.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: bookmark extensions problems
Clay Leeds wrote: > The PDF outline items do *not* appear to show up when I process with > xalan.bat. I am using the "binary" download 0.20.5 version. As I > mentioned before, the strange thing (at least I think it's strange) is > that the example/fo/basic/pdfoutput.fo processes normally and creates > bookmarks. Sorry, I'm even more confused than before. Are you saying that the fox: elements do not even appear in the fo file? 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: 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: 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: 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: URLs in external-graphics -> corrupt PDF
Psi Aushilfe3 wrote: <--- Start --> I was trying to put an absolute http URL into an 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: 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) = & = & etc. > i've also tried this > char(38) = & = & should equal the Adobe standard font. > > but the PDF just shows & > > 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 & 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: Custom TT Fonts not embedded gives garbage
IvanLatysh wrote: > Make shure that you properly generate font metrics, the latest > changes in PSRenderer required to have a WinAnsi encoding. > > [quote] > -enc ansi > With this option you create a WinAnsi encoded font. > > The default is to create a CID keyed font. > If you're not going to use characters outside the > pdfencoding range (almost the same as iso-8889-1) > you can add this option. > [quote] > > for example: > java -cp > ..\lib\fop.jar;..\lib\avalon-framework.jar;..\lib\xml-apis.jar;..\ > lib\xercesImpl-2.2.1.jar;..\lib\xalan-2.4.1.jar > org.apache.fop.fonts.apps.TTFReader -enc ansi %1 %2 If this is affecting documents that don't have fonts embedded, the only way that can be true is for the font metrics to be affecting the actual encoding of the characters in the PDF document itself, which I didn't realize was happening. I knew that there were some encoding issues with TTF fonts, but I thought it was on the embedding side. I will try to take a look at this very shortly, as part of a bunch of font improvements that are now on the drawing 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. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: base URL of Fop Ant Task with Fileset
Enrique Rodriguez wrote:
> I have a directory tree with various folders with diferent depth. On
...
> messagelevel="debug">
>
>
...
> So waht i need is to change the base dir directory for each . fo file of
> the fileset.
OK, I understand.
> What i did is to extend the Fop Task to replace this behaviour. I take
> the Fop 0.20.5 version becouse i have problem with the latest
> nigthly bluid.
>
> This is the little change i make, near line 250
>
> fileSetFOFileBaseURL =f.getParentFile().toURL().toExternalForm();
> Configuration.put("baseDir",fileSetFOFileBaseURL);
>
> I get as basedir the parenFile of the "f", the .fo file of the fileset.
>
> Maybe it will be a good idea to add this configuration to the
> "Key-Value Configuration Options". I think this have sense becouse if
> the .fo file is the source of the translation its folder should be the
> basedir of the translation.
I'm more inclined to think it should be an attribute on the FOP task in Ant,
since I can't think of any other place where it isn't convenient to just use
the baseDir configuration option. If you agree, would you mind adding this
as an enhancement request in Bugzilla?
http://xml.apache.org/fop/bugs.html#issues_new
Be sure to include your proposed patch.
Or, better yet, maybe you would like to go ahead and propose a PATCH to
implement the Ant attribute. I guess it would just be a boolean, perhaps
something like basedirfromfo, where true would implement your change, and
false would use the basedir for the fileset. Or, there may be some other
similar issues that need to be rolled into this idea.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: base URL of Fop Ant Task with Fileset
Enrique Rodriguez wrote: > I'm making one Ant script that convert many xml file to html and pdf. > > I've a litlle proble one i convert the xml file to pdf with the external > resources (iamges). The script catch the base url as the base dir of the > fileset but i think it's better if the base dir would be the folder that > contain the .fo file. > > Anybody think the same as me??? See: http://xml.apache.org/fop/anttask.html#Parameters+for+FOP+Ant+task where the "userconfig" parameter/attribute is discussed. Then see: http://xml.apache.org/fop/configuration.html#summary-key-value where the "basedir" configuration option is discussed. Between the two, I think you should be able to set the base directory to anything you want. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Custom TT Fonts not embedded gives garbage
Ralf Steppacher wrote: > In my case I get random characters. E.g. where it should say "Report > Konzern Lieferantendatenbank" I get "5 H SRUW . RQ] HU Q / L HI H > U D Q W" and so on. I do not see a pattern. If there were a pattern it > would be hard to recognize because of the many spaces in the output. > The type face is correct (Arial). OK, that helps. There are some other font bugs reported, but I don't recognize this one. Jeremias might though. Perhaps the most efficient thing to do is to wait for a response from him. In the meantime, if you like, try cutting some of the jumbled text from your PDF and pasting it into another application. Is the underlying text 1) correct, 2) the same as appears in the PDF, or 3) something else? I will be off-list for most of the next several hours, but will pick this back up again later if needed. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: baseDir not working in fop 0.20.5
Howard Ungar wrote: > content-height="33.05pt" > content-width="36.05pt" > height="33.05pt" > scaling="non-uniform" > src="url(/pdfBill.jpg)" ^ I'm no expert on URI syntax, but I am pretty sure you don't want that "/" when you are trying to reference a resource relative to the base URI. See http://xml.apache.org/fop/fo.html#external-resources for more details. Also, please be sure to double-check that the file really is there. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fonts?
I don't mean to offend anyone participating in this thread, as all are valuable contributors to this project, and I understand that you are trying to improve things. However, I think it may be important to point out that the goal here is not necessarily to make the web site the best that it can be, but rather to make the web-site the best that it can be *cost-effectively*. I doubt that nitpicking the web site colors or the nuances of "compliance" vs. "conformance" are of general interest to this list. I have a suggestion. This is a serious suggestion, not sarcastic or cynical. If you seriously want to discuss such issues, consider creating a separate list for them, perhaps [EMAIL PROTECTED] I may be shot for this, but I'll put up a link on the mailing list page to that list. For each issue, get 10 or more people to vote on it, with at least 2/3 agreeing that a change is needed. (A super-majority is important to prevent flip-flops). Summarize them once a month & submit the package to the fop-dev mailing list. I will do my best to either implement them or explain why not on the fop-nitpick list. If FOP were a mature project with all features implemented and very few bugs to fix, I might take a different attitude. The truth is that we have 3 or 4 active developers who have a large mountain to climb, and IMO it is just wrong to drag them away to deal with issues like this. If there is genuine and general confusion about the content, then *please* continue to raise those on the list, as fixing the doc once is better than answering 100 emails on the same subject. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Custom TT Fonts not embedded gives garbage
Ralf Steppacher wrote: > I have a problem using custom true type fonts that I do not want to > embed into a PDF file. If I do not embed the font acroread displays only > garbage. The font is standard Arial and is definitively installed, the > metric file was generated on the very same machine that is used to > create and display the PDF file. > > I searched the archive and found a posting from about a year ago that > says that not embedding TTFs is not an option. Is this still true or am > I doing something wrong? Please be more specific about "garbage". Are you getting all "#" characters? Are ASCII characters working and nothing else, or is nothing coming through correctly? Can you see any patterns (like an "a" always comes out as a "w")? 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: baseDir not working in fop 0.20.5
Howard Ungar wrote: > Sorry but this doesn't work either. I'm beginning to think the basedir > isn't working at all in 0.20.5. Please check it out and let me know. Howard: Please also show us the XSL-FO code (presumably fo:external-graphic) where you are referencing the file that is generating the error. 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?
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: 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 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: > 1) it's not clear from the opening of that page what table >entries consisting of a single "." represent. the >explanation at the top states simply that blue means >supported, and red means unsupported. > >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 but the last time I checked it didn't work with our web publishing workflow. > 2) all of the tag links from the top of that page don't work, >since the fragments are named with: > >... > >rather than the correct > > Oops. I never noticed that because they work fine in my browser. Thanks for pointing that out. I just committed & published a fix for this. It should be live on the web site in about an hour (midnight Pacific time). 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: Large Memory Footprints-FOP status
Jenkins, Mark wrote: > FOP appears to be hogging a large memory utilization. > I'm creating a 20 page dynamic pdf with embedded SVG graphs on > each page and > it looks like FOP requires about 120M to produce the 793K pdf on our UNIX > server. > If I start getting a lot of hits I might have to consider offloading FOP > processing to it's own server. > I have implemented page-sequences for each page to try to optimize memory. > I'm using the 5/20/2003 fop.jar. > I read that the ALT DESIGN is attempting to address some of these > issues but > I need a solution pretty soon and don't know if/when this will come to > fruition. > Does anyone have any recommendations? 1) help with the redevelopment, 2) fund someone who is helping with the redevelopment, 3) use a different implementation, or 4) be patient. 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: 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: Is there a way to 'squish' a font?
Teator, Michael wrote: > Basically I'd like to adjust a font's aspect ratio, adjust it's height but > not it's width. Possible? Possible in PostScript (see makefont), and PDF (see Tz operator), but AFAIK not defined in XSL-FO. I expect to see it in some future release of the standard, and I think it would be pretty feasible to write an extension to do it now. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: External graphic referencing within a servlet
Clay Leeds wrote (a long time ago, May 21, 2003 to be exact): > On 5/21/2003 9:18 AM, Jeremias Maerki wrote: > > You may need to the the base directory/URL. See: > > http://xml.apache.org/fop/embedding.html#config-internal > > > > But I think your src attribute is wrong. It should be something like > > this: src="url(file:logo.gif)". > > I was thinking it was this: > > src="url(logo.gif)"/> > > or if it were in sub-directory "images/" it would look like this: > > src="url(images/logo.gif)"/> > > Yup! 'Just looked, and that's how it's written on page 93 of Dave > Pawson's O'Reilly book "XSL-FO: Making XML Look Good in Print". First, again I apologize for being so slow. I am cleaning out old items that I had marked for followup. You are both right. Jeremias has included the URI scheme to be more explicit. The URI you reference is relative to the base URI. > BTW, Page 652 of Elliotte Rusty Harold's XML Bible indicates it should > be written like as follows: > > > >http://www.medata.com/images/logo.jpg"/> > > ...hmmm... Probably based on a pre-release version of the spec. Pawson's book indicates that there was some controversy about whether to use URIs. > I just checked the spec: > > fo:external-graphic > http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_external-graphic > > src > http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#src > > and they didn't have an example (D'oh!, why don't they give examples!?) The URI spec is pretty flexible, and documenting a useful range of examples would be a big job, and no doubt considered outside the scope of the spec, which is after all a spec, not a tuturial, and certainly not a tutorial on URI. What *is* there is a definition of the uri-specification datatype, including a reference to the URI spec itself: http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#section-N8794-Propert y-Datatypes (Yes, it would have been helpful for them to link from the "src" definition to the datatype definition). > I also looked at zvon.org, and they show it as: > Just missing the url() syntax. Again, perhaps an old version of the spec. > NOTE-TO-VICTOR: Once we get this completely straightened out, this info > might be useful at the top of the graphics page, to help newbies craft > this little call (although we could also include the plethora of > whichever functioning options will work). I use the following (works > perfectly), so we might just want to use it as our example: > > height=".99cm" content-width="1.87cm" content-height=".99cm" border="0"/> OK, I have added a section to our XSL-FO page which documents how to reference "External Resources", esp. those on local filesystems, and I have updated our FAQ page to point to this. Since this is *strictly* an XSL-FO issue, and since it can be found through the FAQ already, I'm going to keep it off of our Graphics page, although we can add a link from there to the "External Resources" doc later if it looks like it is needed. These changes are in CVS, & will be published in the next week or so. 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: 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: 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: > > > hyphenation-dir > /java/fop-0.20.4/hyph > 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: 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-maintain&content-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: PDF in Asian languages (Simplified Chinese,Traditional Chinese, Japanese,Korean)
Tom Chen wrote: > 1) Do you imply that adding the metrics xml files generated from Adobe > Asian Font Pack or the 6.0 Reader(without embedding the font file e.g. TTF > file) doesn't raise license problem? Correct (with the usual disclaimer about not being a lawyer). If have some information to the contrary, please let me know. If you have a license to use the font in question, and if you are not distributing it (i.e. embedding it in this case), there should be no problem with distributing PDF files that are created using the font metrics for that font. The font vendor gets his money from the people who need to open the file. To take this a step further, we use mostly Adobe fonts, and one reason for that is that all of them that I know of include a license to embed the file into a PDF document. (We won't license fonts that don't allow embedding -- the PDF is or should be the equivalent of paper, and nobody thinks the user of a paper document should have to license the fonts that created it). Now, there *could* be a problem with FOP distributing the metric files with its software. That probably deserves closer inspection, but I am assuming for the moment that these Asian fonts are provided on a similar basis to the Base-14 fonts. > 2) Do you where we can find the spec for those Adobe Asian Font Pack? I would start by looking at the links listed here: http://xml.apache.org/fop/resources.html#documents-pdf You'll probably need to dig around a bit on the Adobe site. I have a copy of Acrobat 6.0 Pro sitting on my desk uninstalled, but it will be a while before I can dive into that. 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: 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: > 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: 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: 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: 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: Website update?
Ben Galbraith wrote: > I believe the FOP website lurks on this list, right? Most of the developers help maintain the content, but I have probably been most heavily involved with doc in recent days. > I have done some further research on exactly what image support FOP > offers, in efforts to figure out how to embed CMYK images into a > resultant PDF. Perhaps this information will be of use to others. Thanks very much for documenting all of this. I wish we had the resources to just go fix all of this, but the next best thing is to document it. > Here's what I've found: > > Native TIFF > - only supports 1 sample per pixel images > - only supports "white-is-zero" and RGB photometric interpretation > (although due to the sample per pixel limitation above, RGB images are > unsupported)\ I'm no expert here, but I waded through the TIFF spec a bit, and offer the following paraphrase, which I ask you to either confirm or deny: What TIFF calls sample-per-pixel is the number of channels. So WhiteIsZero can support bi-level and grayscale images through that one channel. But RGB photometric interpretation needs at least three channels, and only has 1 to work with, therefore no color. RGB Palette could use that one channel for a 256-color palette, but it is unsupported. So the bottom line is that FOP native can't support color TIFF images at all, RGB or otherwise. > - appears to support the following compression schemes: >- CCITT T.4 bi-level encoding >- CCITT T.6 bi-level encoding >- JPEG compression > > JAI TIFF > - images MUST be RGB > - RGBA appears to be supported to some degree > - all other support should be consistent with JAI > > JAI PNG > - images MUST be RGB > - RGBA appears to be supported to some degree > - all other support should be consistent with JAI > > Native JPG > - grayscale, RGB, and CMYK appear to be supported > > Native BMP > - images must be RGB > > I can provide more granular information if necessary. As a result of my > findings, it is clear that for embedding CMYK images into a resultant > PDF, JPG is the only game in town. The rest of this I follow, and will make changes to the website accordingly. Again, thanks for your efforts here. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
