Re: PSDocumentGraphics2D and Font dictionary

On 13.09.2005 00:53:56 Vincent Hennebert wrote: > Well, so there is no simple solution :-( > > I could probably add a method like getConfiguredFonts in the font server to > put > in the postscript file all of the fonts defined in the config file. But that > really sounds dirty to me. > > A te

Re: fo:inline bpd

On Tue, 13 Sep 2005 01:26 am, Finn Bock wrote: > > Manuel Mall wrote: > >> yes, that is an option. What I am unsure about here is that the > >> children, typically text areas, do not take the line spacing into > >> account when reporting their bpd, that is the usually 10% space > >> above and below

Re: PSDocumentGraphics2D and Font dictionary

Well, so there is no simple solution :-( I could probably add a method like getConfiguredFonts in the font server to put in the postscript file all of the fonts defined in the config file. But that really sounds dirty to me. A temporary solution (before implementing a two-pass approach) would

DO NOT REPLY [Bug 36625] - Percentage IPD incorrect in side regions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36625] - Percentage IPD incorrect in side regions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36625] - Percentage IPD incorrect in side regions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36625] - Percentage IPD incorrect in side regions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36625] - Percentage IPD incorrect in side regions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36625] - Percentage IPD incorrect in side regions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36625] New: - Percentage IPD incorrect in side regions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: PSDocumentGraphics2D and Font dictionary

I know exactly what you mean. The only way around this is to do a two-pass approach when writing PostScript, meaning that you keep track of resources (like fonts) while writing the pages and later you put together the complete PostScript document by including the needed resources in the right place

Re: Another table-question: initial column-number for cells

On Sep 12, 2005, at 12:01, Andreas L Delmelle wrote: FYI: I'm currently almost done with having the initial values set by the Property subsystem itself. (Finn's recent addition of TableBorderPrecedence gave me just the hint I needed to get the necessary understanding of the property system...)

Re: Hyphenation

Manuel Mall wrote: I noticed we don't have any hyphenation testcases in the layout engine test suite. I'm working on that, as well as on test case for TR14 compatible line breaking (not yet implemented though...). J.Pietschmann

PSDocumentGraphics2D and Font dictionary

In PSDocumentGraphics2D.writeFileHeader (and also in PSRenderer.startPageSequence) the font dictionary is written into the PS file by a call to PSFontUtil.writeFontDict. At this time all of the fonts present in the fontInfo (defaults + those found in the config file) seem to be written out, even

Re: FOrayFont, PS/PDFTranscoders and SVG handling

Jeremias and Victor, thanks for the hints. I keep them under the hand for later, when it is time to migrate the stuff into XML Graphics Commons. For now I just override current implementations with FOrayFont. Anyway it will possible to recover them with svn, in case they have to coexist. Vinc

Re: fo:inline bpd

Manuel Mall wrote: yes, that is an option. What I am unsure about here is that the children, typically text areas, do not take the line spacing into account when reporting their bpd, that is the usually 10% space above and below the character. So what is the correct bpd for an fo:inline which

RE: FOrayFont, PS/PDFTranscoders and SVG handling

Jeremias Maerki wrote: > For the drawString() methods we can create simple plug-ins > much like the TextElementBridges which are called by the > drawString() methods. Two implementations of the plug-in > interface: One to paint using the new font subsystem and one > that uses the Java2D font s

Re: fo:inline bpd

On Mon, 12 Sep 2005 07:52 pm, Luca Furini wrote: > Manuel Mall wrote: > > yes, that is an option. What I am unsure about here is that the > > children, typically text areas, do not take the line spacing into > > account when reporting their bpd, that is the usually 10% space > > above and below the

Re: FOrayFont, PS/PDFTranscoders and SVG handling

First of all, the SVG handling code in FOP (except for the XMLHandlers) among other stuff will move out of FOP. See here: http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents I assume this will happen after the first preview release and after you finish your work on FOrayFont integration

FOrayFont, PS/PDFTranscoders and SVG handling

I'm about to convert the SVG library to FOrayFont. But the Batik side seems to be reluctant to see the transcoders converted to FOrayFont [1]. How should I handle that? I guess I should leave existing files as is and provide new files corresponding to the FOrayFont implementation? How should I n

Re: Hyphenation

On Sep 12, 2005, at 12:48, Manuel Mall wrote: On Mon, 12 Sep 2005 06:17 pm, Andreas L Delmelle wrote: BTW: On the release-plan Wiki, I noticed that the hyphenation patterns still haven't been removed yet. I remember running into problems while trying to remove them a couple of months ago, so th

Re: fo:inline bpd

Manuel Mall wrote: yes, that is an option. What I am unsure about here is that the children, typically text areas, do not take the line spacing into account when reporting their bpd, that is the usually 10% space above and below the character. So what is the correct bpd for an fo:inline which

Re: fo:inline bpd

Luca, yes, that is an option. What I am unsure about here is that the children, typically text areas, do not take the line spacing into account when reporting their bpd, that is the usually 10% space above and below the character. So what is the correct bpd for an fo:inline which has text area

Re: fo:inline bpd

Some days ago, Manuel Mall wrote: The problem is that the Inline LM doesn't calculate the dimension of the area it is suppose to construct from the subsequence given to it by the Line LM. Instead it just assumes the dimension of the line as given to it in the LayoutContext. However, to be ab

Re: Hyphenation

On Mon, 12 Sep 2005 06:17 pm, Andreas L Delmelle wrote: > On Sep 12, 2005, at 12:06, Jeremias Maerki wrote: > > Uhm, given that we've decided to remove the hyphenation patterns > > entirely, we can't do these tests at all. D'oh! I don't quite understand that argument. Just because we don't distrib

Re: Hyphenation

On Sep 12, 2005, at 12:06, Jeremias Maerki wrote: Uhm, given that we've decided to remove the hyphenation patterns entirely, we can't do these tests at all. D'oh! BTW: On the release-plan Wiki, I noticed that the hyphenation patterns still haven't been removed yet. I remember running into pro

Re: Hyphenation

Uhm, given that we've decided to remove the hyphenation patterns entirely, we can't do these tests at all. D'oh! BTW, which of the rhaeto-romanic dialects would you like to have hyphenation files for? Probably at least the (artificial) Rumantsch Grischun but some people from that area would probab

Re: Another table-question: initial column-number for cells

On Sep 12, 2005, at 11:49, Jeremias Maerki wrote: The current code works that way. The first free grid unit is used. OK. Thanks for the confirmation. FYI: I'm currently almost done with having the initial values set by the Property subsystem itself. (Finn's recent addition of TableBorderPre

Re: Another table-question: initial column-number for cells

The current code works that way. The first free grid unit is used. See table-cell_number-rows-spanned.xml On 12.09.2005 11:22:19 Andreas L Delmelle wrote: > Hi, > > The Rec describes the default value for the column-number on > table-cells as: > "For the first table-cell in a table-row, the cur

Hyphenation

I noticed we don't have any hyphenation testcases in the layout engine test suite. Are there any handy samples around for different languages? German is easy with words like: Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz and Donaudampfschiffahrtselektrizitaetenhauptbetriebswerkbau

Another table-question: initial column-number for cells

Hi, The Rec describes the default value for the column-number on table-cells as: "For the first table-cell in a table-row, the current column number is 1..." My question: is this also true in case there was a row-spanning cell from the previous row that already occupies the first column? IOW

Re: svn commit: r279551 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java test/layoutengine/testcases/wrapper_text-transform_1.xml

Luca, I just noticed that the new Knuth sequences proposed below break the removal of spaces at the end of paragraphs as the assumptions made in the code about the sequence of Knuth elements signifying a space are not true any more. This can happen if we have a inside a and the inline has bo

DO NOT REPLY [Bug 36533] - Incorrect ipd and twsadjust settings

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 25732] - [PATCH] Supress leading spaces after a line-break.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36068] - Inconsistency in property parsing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu