On 25.02.2004 17:32:14 ARDOIN JEAN-LUC wrote: > Thanks a lot for your answers, but Krysalis can't solve this.
Not the whole thing, but it would be easy to do the painting part. Implementing a new barcode type is pretty easy. I'll gladly assist if anyone wants to try. > The only solution, i found is counting lines of data to draw marks, but > when changing caract. size, sub-totals or anything else bind with datas, > number of pages changes and the OMR marks are wrong. > > I thought about extension because the number of pages is only known > during the fop process and OMR needs this information. Fop extensions > are, for me, a way add java to expand FOP process. Am I wrong ? Not really. Let me tell you how I solved the OMR problem two years ago. I've post-processed the PostScript files by manually inserting the OMR painting code (in PostScript commands) into the PostScript files. The DSC (document structuring conventions) help you a lot to find the right places. I used a mix of the following to calculate the right combination of marks for the OMR code: - I used page-sequences to delimit individual documents in the whole rendering run (see next point). - I created the FormattingResults object you can get from the Driver object that tells you about the overall number of pages and the page-sequences that have been generated. That's how you get to know about the outline of the generated document. See http://xml.apache.org/fop/embedding.html#render-info - I used separate rules to determine when to trigger which insertions. - An OMR control class was then fed with all the information during the scanning and patching process for the generated PostScript file. Its output was used to paint the right OMR marks. (Please don't ask me to publish to code because I can't. I don't own it.) > OMR managment seems to be really a limitation of FOP. That depends if you see this as a requirement for FOP. I decided for a post-processing aproach because it allows you, as a bonus, to use the code to patch almost any PostScript stream that conforms to the DSC conventions. I'm sure FOP can be improved to provide a better infrastructure for OMR mark production but you have to keep in mind that there are quite a few differing OMR systems available. You've also got other packaging systems using 1D-barcodes ("normal" barcodes) as well as 2D-barcodes such as DataMatrix. I know this topic has been discussed a few times on this list. I suggest interested parties create a new page on the Wiki (http://nagoya.apache.org/wiki/apachewiki.cgi?FOPProjectPages) and collect your findings there. You might also find some additional information in the mailing list archive. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
