Re: Dramatic improvement of PDF text painting quality for SVG
Not anymore. But remember that in order to include FOP's transcoders in Batik, a release needs to be made, which means a branch, which means an opportunity to temporarily work around these things. BTW, the EPS transcoder is currently broken. Everything is upside down and I haven't investigated, yet. Don't know where and when it got broken. This all just reminds me that we need to get this stuff out of FOP. I'm still on the image package redesign and will have to do a few smaller things afterwards. But after that I want to get this done. Jeremias Maerki On 06.11.2007 00:43:34 Cameron McCormack wrote: > Jeremias Maerki: > > As you may have see, I've reimplemented the PDFTextPainter which is part > > of the PDFTranscoder. All most all text is now painted using PDF text > > painting primitives (except for SVG fonts and where filters are used). > > By the way, is the FOP code after this commit still able to be compiled > with Java 1.3? I would like this change to be in the final Batik 1.7 > release (whenever that happens, maybe in a few weeks). > > -- > Cameron McCormack, http://mcc.id.au/ > xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
Re: Dramatic improvement of PDF text painting quality for SVG
Jeremias Maerki: > As you may have see, I've reimplemented the PDFTextPainter which is part > of the PDFTranscoder. All most all text is now painted using PDF text > painting primitives (except for SVG fonts and where filters are used). By the way, is the FOP code after this commit still able to be compiled with Java 1.3? I would like this change to be in the final Batik 1.7 release (whenever that happens, maybe in a few weeks). -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
Re: First steps towards an implementation for fo:inline-container
Very cool, Andreas! Actually, I don't see why you shouldn't commit what you have if it is a step forward an inline-container was basically unusable before. About your question (probably not very helpful): I'm not sure (Manuel is our baseline master) but why don't you take a look at AbstractGraphicsLayoutManager? external-graphic and i-f-o both generate a viewport/reference pair. I suspect that you simply have to provide a makeAlignmentContext(LayoutContext) method. Figuring out the right values there (given the baseline instructions for i-c) is another story, I guess. But one step at a time... HTH Jeremias Maerki On 05.11.2007 21:18:14 Andreas L Delmelle wrote: > > Hi people > > I've recently (finally) started looking at implementing fo:inline- > container, and got to my first promising results, so just thought I'd > share, should there be any interested parties. > > OTOH, I've also run into a few obstacles I'm unsure how to deal with, > so... > > The rough InlineContainerLayoutManager implementation I have now > still descends from LeafNodeLayoutManager. No idea if that's going to > be enough in the long run, but for now I did manage to get some > simple examples working without changing this. > > The generation of the element list is no particular problem. > Basically the same as blocks in an fo:inline, only slightly simpler > because the inline-container can /only/ contain block-sequences, and > as such there is no need to worry about closing any open paragraphs. > So far I only got it working for a sequence of one or more fo:blocks, > though. The sequences returned for an fo:table or an fo:list-block > seem to confuse the LineBreakingAlgorithm for the containing Block > once the inline table/list contains more than one row/item. Haven't > looked too deep into that, but it seems to be something like: the > algorithm expects to find a KnuthElement, but finds something else (a > KnuthSequence, probably => ClassCastException in > BreakingAlgorithm.getElement()). > > ATM, in the basic getNextKnuthElements(), little more happens than: > > KnuthSequence inlineSequence = new InlineKnuthSequence(); > ... > while (curLM ...) { > ... > returnedList = curLM.getNextKnuthElements(...); > ... > KnuthSequence tmpSeq = new BlockKnuthSequence(returnedList); > seq.wrapPositions(this); > inlineSeq.addAll(seq); > } > > Qua area-generation, it is set up as a viewport/reference area pair, > where the viewport is the same Viewport type used for the images and > the reference-area is an InlineBlockParent. > Currently, I still sort of hacked the structure together: > * the reference-area has a single Block child that is used to add the > childAreas to > * at the end of the addAreas() loop, the viewport's content is set to > the reference-area > > Maybe it would be slightly better to allow InlineBlockParent to have > multiple children, but for now, inserting that dummy Block seemed the > least intrusive way of reaching the goal. > > Anyways, a small addition to cater for rendering an InlineBlockParent > in AbstractRenderer.renderViewport() did the rest. > > One of the obstacles I'm running into now, and I'm hoping someone > might be able to provide pointers for, is adjusting the line-height. > See the attachment, where the inner blocks already appear nicely in > position, but the following line still overlaps. :( > > > It's not ready for a commit yet, but I do hope to get it in a more > usable state soon, so we can finally claim support for the XSL-FO > equivalent of HTML's IFRAME. > > > Cheers > > Andreas >
Re: svn commit: r591583 - in /xmlgraphics/fop/trunk/src: codegen/fonts/ java/org/apache/fop/fonts/ java/org/apache/fop/pdf/
On Nov 5, 2007, at 12:42, Vincent Hennebert wrote: Jeremias Maerki wrote: Statistical interest. Increasing a long shouldn't use many more CPU cycles than setting a boolean to true, right? That’s not a problem of performance. When I see this I simply wonder why a long is used while a boolean would be sufficient. Statistical interest, why not, although here it only exists when doing a manual debugging session. That’s not a very big deal anyway since here the class is small, but when you encounter such variables in hundreds of other lines of codes, believe me, it takes a while before figuring out that they are actually used as booleans... True, or should I say 'one' :-) Funny, this description somehow reminds me of the times when I familiarized myself with the "good old" Win32 API... ;-) Cheers Andreas
First steps towards an implementation for fo:inline-container
Hi people I've recently (finally) started looking at implementing fo:inline- container, and got to my first promising results, so just thought I'd share, should there be any interested parties. OTOH, I've also run into a few obstacles I'm unsure how to deal with, so... The rough InlineContainerLayoutManager implementation I have now still descends from LeafNodeLayoutManager. No idea if that's going to be enough in the long run, but for now I did manage to get some simple examples working without changing this. The generation of the element list is no particular problem. Basically the same as blocks in an fo:inline, only slightly simpler because the inline-container can /only/ contain block-sequences, and as such there is no need to worry about closing any open paragraphs. So far I only got it working for a sequence of one or more fo:blocks, though. The sequences returned for an fo:table or an fo:list-block seem to confuse the LineBreakingAlgorithm for the containing Block once the inline table/list contains more than one row/item. Haven't looked too deep into that, but it seems to be something like: the algorithm expects to find a KnuthElement, but finds something else (a KnuthSequence, probably => ClassCastException in BreakingAlgorithm.getElement()). ATM, in the basic getNextKnuthElements(), little more happens than: KnuthSequence inlineSequence = new InlineKnuthSequence(); ... while (curLM ...) { ... returnedList = curLM.getNextKnuthElements(...); ... KnuthSequence tmpSeq = new BlockKnuthSequence(returnedList); seq.wrapPositions(this); inlineSeq.addAll(seq); } Qua area-generation, it is set up as a viewport/reference area pair, where the viewport is the same Viewport type used for the images and the reference-area is an InlineBlockParent. Currently, I still sort of hacked the structure together: * the reference-area has a single Block child that is used to add the childAreas to * at the end of the addAreas() loop, the viewport's content is set to the reference-area Maybe it would be slightly better to allow InlineBlockParent to have multiple children, but for now, inserting that dummy Block seemed the least intrusive way of reaching the goal. Anyways, a small addition to cater for rendering an InlineBlockParent in AbstractRenderer.renderViewport() did the rest. One of the obstacles I'm running into now, and I'm hoping someone might be able to provide pointers for, is adjusting the line-height. See the attachment, where the inner blocks already appear nicely in position, but the following line still overlaps. :( It's not ready for a commit yet, but I do hope to get it in a more usable state soon, so we can finally claim support for the XSL-FO equivalent of HTML's IFRAME. Cheers Andreas test.at.pdf Description: Adobe PDF document
Re: svn commit: r591587 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/render/ps/ src/java/org/apache/fop/svg/
On 05.11.2007 15:37:29 Vincent Hennebert wrote: > >> - in PDFTextPainter: now that the code is working, you probably want to > >> remove the DEBUG variable and all the statements displaying stuff to > >> System.out; or replace them with proper log.debug statements ;-) > > > > No, I don't. The debug code is most probably optimized away by the > > compiler so it doesn't bother us at runtime. If any bugs arise, it's > > Except if the DEBUG variable is left to true... Oh, that was a mistake. I thought I switched it to false. Thanks for correcting it. Jeremias Maerki
Re: svn commit: r591587 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/render/ps/ src/java/org/apache/fop/svg/
Jeremias Maerki wrote: >> - it seems to me that a bit more of the internal state of >> a PDFTextUtil object could be controlled by the object itself, >> especially in the following piece of code (PDFTextPainter, l.220): >> Font f = textUtil.selectFontForChar(ch); >> if (f != textUtil.getCurrentFont()) { >> textUtil.writeTJ(); >> textUtil.setCurrentFont(f); >> textUtil.writeTf(f); >> textUtil.writeTextMatrix(localTransform); >> } >> A signalFontUsed(f) method might make sense. Basically doing the >> same test as above, but inside PDFTextUtil. The code would be better >> encapsulated, so more maintainable. WDYT? > > Again, feel free to change and improve. Ok. It’s just that I’m reluctant to modify code I’m not familiar with, and from which I may have missed the logic. >> - in PDFTextPainter: now that the code is working, you probably want to >> remove the DEBUG variable and all the statements displaying stuff to >> System.out; or replace them with proper log.debug statements ;-) > > No, I don't. The debug code is most probably optimized away by the > compiler so it doesn't bother us at runtime. If any bugs arise, it's Except if the DEBUG variable is left to true... > convenient to switch on. Most importantly, though, the Batik guys have > indicated that they don't want to work with a logging framework. Since > this code is destined to go to Batik I try not to introduce more Commons > Logging in this area. Vincent
Re: svn commit: r591587 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/render/ps/ src/java/org/apache/fop/svg/
On 05.11.2007 13:05:29 Vincent Hennebert wrote: > Hi Jeremias, > > I’d have a couple of comments regarding your changes. I’ve only had > a quick look and don’t understand this part of the code well, but > following the principle of pair review, here they are: > > - at several places there is code like the following: > private void checkInTextObject() { > if (!inTextObject) { > throw new IllegalStateException("Not in text object"); > } > } > I understand and don’t criticise the need for safety checks, > especially if the code is new or complex. Only, since we now have > Java 1.4 as a minimal requirement, why not use assert statements? They > were created exactly for that. I could do a lot of stuff. I'm so used to working pre-Java-1.4 that it didn't occur to me. Feel free to change. There's no code-ownership in Apache projects. > - in PDFTextUtil: > - the setTextRenderingMode(int) method is only used within > PDFTextUtil; why then not making it private? The other > setTextRenderingMode method will still be available and seems to be > much safer to use anyway. PDFTextUtil is designed to be useful for classes other than PDFTextPainter. Someone might prefer working more closely to the PDF spec and therefore prefer the int variant. > - it seems to me that a bit more of the internal state of > a PDFTextUtil object could be controlled by the object itself, > especially in the following piece of code (PDFTextPainter, l.220): > Font f = textUtil.selectFontForChar(ch); > if (f != textUtil.getCurrentFont()) { > textUtil.writeTJ(); > textUtil.setCurrentFont(f); > textUtil.writeTf(f); > textUtil.writeTextMatrix(localTransform); > } > A signalFontUsed(f) method might make sense. Basically doing the > same test as above, but inside PDFTextUtil. The code would be better > encapsulated, so more maintainable. WDYT? Again, feel free to change and improve. > - in PDFTextPainter: now that the code is working, you probably want to > remove the DEBUG variable and all the statements displaying stuff to > System.out; or replace them with proper log.debug statements ;-) No, I don't. The debug code is most probably optimized away by the compiler so it doesn't bother us at runtime. If any bugs arise, it's convenient to switch on. Most importantly, though, the Batik guys have indicated that they don't want to work with a logging framework. Since this code is destined to go to Batik I try not to introduce more Commons Logging in this area. > For the rest I believe when you say it’s working... Congrats! > > Vincent Jeremias Maerki
Re: svn commit: r591587 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/render/ps/ src/java/org/apache/fop/svg/
Hi Jeremias, I’d have a couple of comments regarding your changes. I’ve only had a quick look and don’t understand this part of the code well, but following the principle of pair review, here they are: - at several places there is code like the following: private void checkInTextObject() { if (!inTextObject) { throw new IllegalStateException("Not in text object"); } } I understand and don’t criticise the need for safety checks, especially if the code is new or complex. Only, since we now have Java 1.4 as a minimal requirement, why not use assert statements? They were created exactly for that. - in PDFTextUtil: - the setTextRenderingMode(int) method is only used within PDFTextUtil; why then not making it private? The other setTextRenderingMode method will still be available and seems to be much safer to use anyway. - it seems to me that a bit more of the internal state of a PDFTextUtil object could be controlled by the object itself, especially in the following piece of code (PDFTextPainter, l.220): Font f = textUtil.selectFontForChar(ch); if (f != textUtil.getCurrentFont()) { textUtil.writeTJ(); textUtil.setCurrentFont(f); textUtil.writeTf(f); textUtil.writeTextMatrix(localTransform); } A signalFontUsed(f) method might make sense. Basically doing the same test as above, but inside PDFTextUtil. The code would be better encapsulated, so more maintainable. WDYT? - in PDFTextPainter: now that the code is working, you probably want to remove the DEBUG variable and all the statements displaying stuff to System.out; or replace them with proper log.debug statements ;-) For the rest I believe when you say it’s working... Congrats! Vincent
Re: svn commit: r591583 - in /xmlgraphics/fop/trunk/src: codegen/fonts/ java/org/apache/fop/fonts/ java/org/apache/fop/pdf/
Jeremias Maerki wrote: > Statistical interest. Increasing a long shouldn't use many more CPU > cycles than setting a boolean to true, right? That’s not a problem of performance. When I see this I simply wonder why a long is used while a boolean would be sufficient. Statistical interest, why not, although here it only exists when doing a manual debugging session. That’s not a very big deal anyway since here the class is small, but when you encounter such variables in hundreds of other lines of codes, believe me, it takes a while before figuring out that they are actually used as booleans... A small comment, perhaps? Vincent
Re: svn commit: r591583 - in /xmlgraphics/fop/trunk/src: codegen/fonts/ java/org/apache/fop/fonts/ java/org/apache/fop/pdf/
Statistical interest. Increasing a long shouldn't use many more CPU cycles than setting a boolean to true, right? Jeremias Maerki On 05.11.2007 11:32:09 Vincent Hennebert wrote: > Hi Jeremias, > > > Modified: > > xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java > > URL: > > http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java?rev=591583&r1=591582&r2=591583&view=diff > > == > > --- xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java > > (original) > > +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java Sat > > Nov 3 03:51:31 2007 > > @@ -27,6 +27,8 @@ > > */ > > public abstract class Typeface implements FontMetrics { > > > > +private long charMapOps = 0; > > + > > /** > > * Get the encoding of the font. > > * @return the encoding > > @@ -39,6 +41,23 @@ > > * @return the mapped character > > */ > > public abstract char mapChar(char c); > > + > > +/** > > + * Used for keeping track of character mapping operations in order to > > determine if a font > > + * was used at all or not. > > + */ > > +protected void notifyMapOperation() { > > +this.charMapOps++; > > +} > > + > > +/** > > + * Indicates whether this font had to do any character mapping > > operations. If that was > > + * not the case, it's an indication that the font has never actually > > been used. > > + * @return true if the font had to do any character mapping operations > > + */ > > +public boolean hadMappingOperations() { > > +return (this.charMapOps > 0); > > +} > > Basically you need to know whether the font has been used or not. Then > why not just use a boolean for charMapOps? > > Vincent
Re: svn commit: r591583 - in /xmlgraphics/fop/trunk/src: codegen/fonts/ java/org/apache/fop/fonts/ java/org/apache/fop/pdf/
Hi Jeremias, > Modified: > xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java > URL: > http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java?rev=591583&r1=591582&r2=591583&view=diff > == > --- xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java > (original) > +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java Sat Nov > 3 03:51:31 2007 > @@ -27,6 +27,8 @@ > */ > public abstract class Typeface implements FontMetrics { > > +private long charMapOps = 0; > + > /** > * Get the encoding of the font. > * @return the encoding > @@ -39,6 +41,23 @@ > * @return the mapped character > */ > public abstract char mapChar(char c); > + > +/** > + * Used for keeping track of character mapping operations in order to > determine if a font > + * was used at all or not. > + */ > +protected void notifyMapOperation() { > +this.charMapOps++; > +} > + > +/** > + * Indicates whether this font had to do any character mapping > operations. If that was > + * not the case, it's an indication that the font has never actually > been used. > + * @return true if the font had to do any character mapping operations > + */ > +public boolean hadMappingOperations() { > +return (this.charMapOps > 0); > +} Basically you need to know whether the font has been used or not. Then why not just use a boolean for charMapOps? Vincent
Re: Dramatic improvement of PDF text painting quality for SVG
On 05.11.2007 08:22:38 Max Berger wrote: > Jeremias, > > > Am Samstag, den 03.11.2007, 12:22 +0100 schrieb Jeremias Maerki: > > Implementation notes: > > - The text painter has a fallback so it can still paint text with SVG > > fonts. Text for which there's no font in FOP's FontInfo object will be > > painted using shapes as before. > > Please correct me if I'm wrong: > > AFAIK fop does not embed fonts into the document unless explicitly > requested. So with the new auto-detection feature, it will automatically > pick up all fonts on the local system, and provide font-metrics > (FontInfo) for it, but not embed them. No, it does embed them by default! I think we don't have a facility to suppress font embedding for auto-detected fonts, yet. > If the resulting pdf is moved to > a different machine where the installed font set is different, the > result will look very garbled. No, it doesn't affect the resulting PDF because the fonts are embedded. > > Feedback welcome. And yes, XSL-FO documents with embedded SVG profit > > from these changes, too. :-) > > Have fun! > > Jeremias Maerki > > > Max Jeremias Maerki