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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36068. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36068 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 10:06 --- Fixed in revision 280286. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=25732. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25732 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 10:12 --- Problem fixed long ago by knuth algo, patch no longer valid anyway. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36533. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36533 --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 11:04 --- Oops! I see the problem, and I know the reason: I fixed the method getNextKnuthElements() but forgot to fix getChangedKnuthElements() too ... Well, I think it's time for me to factor out some duplicated lines! :-) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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 fo:block inside a
fo:inline and the inline has border / padding with
conditionality=retain. In this (convoluted) scenario we have a
paragraph end in the middle of a fo:inline which has a right border.
Any ideas how to fix that apart from having complicated 'if' statements
in the trailing spaces removal code?
Manuel
On Thu, 8 Sep 2005 09:55 pm, Luca Furini wrote:
Manuel Mall wrote:
this is my code after integrating your patch to add the knuth
elements for line end / start border/padding for the common
justify=start or end case. What I am getting now is a space at
the beginning of each line break!:
if (lineStartBAP != 0 || lineEndBAP != 0) {
sequence.add
(new KnuthGlue(lineEndBAP, 0, 0,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthPenalty(0, 0, false,
new LeafPosition(this, -1),
true)); sequence.add
(new KnuthGlue(wordSpaceIPD.opt - (lineStartBAP +
lineEndBAP), wordSpaceIPD.max - wordSpaceIPD.opt, wordSpaceIPD.opt
- wordSpaceIPD.min, new LeafPosition(this, -1), true));
sequence.add
(new KnuthInlineBox(0, 0, 0, 0,
notifyPos(new LeafPosition(this, -1)), true));
sequence.add
(new KnuthPenalty(0, KnuthElement.INFINITE, false,
new LeafPosition(this, -1),
true)); sequence.add
(new KnuthGlue(lineStartBAP, 0, 0,
new LeafPosition(this, vecAreaInfo.size() - 1),
false)); } else {
...
}
The LeafPosition(this, vecAreaInfo.size() - 1) (the Position
containing the index of the AreaInfo objects storing information
about the space) should be the one that is discared if a line break
happens: i.e. the second one instead of the third.
With this change, this sequence should be correct for a space in
justified text.
With left- / right-aligned text the overall stretch and shrink of the
sequence should not be changed, so the sequence should be:
sequence.add
(new KnuthGlue(lineEndBAP, 3 *
LineLayoutManager.DEFAULT_SPACE_WIDTH, 0, new LeafPosition(this, -1),
true)); sequence.add
(new KnuthPenalty(0, 0, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(wordSpaceIPD.opt - (lineStartBAP +
lineEndBAP), - 3 * LineLayoutManager.DEFAULT_SPACE_WIDTH, 0,
new LeafPosition(***, false));
sequence.add
(new KnuthInlineBox(0, 0, 0, 0,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthPenalty(0, KnuthElement.INFINITE, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(lineStartBAP, 0, 0,
new LeafPosition(this, -1), true));
With centered text the combined sequence should be:
sequence.add
(new KnuthGlue(lineEndBAP, 3 *
LineLayoutManager.DEFAULT_SPACE_WIDTH, 0, new LeafPosition(this, -1),
true)); sequence.add
(new KnuthPenalty(0, 0, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(wordSpaceIPD.opt - (lineStartBAP +
lineEndBAP), - 6 * LineLayoutManager.DEFAULT_SPACE_WIDTH, 0,
new LeafPosition(***, false));
sequence.add
(new KnuthInlineBox(0, 0, 0, 0,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthPenalty(0, KnuthElement.INFINITE, false,
new LeafPosition(this, -1), true));
sequence.add
(new KnuthGlue(lineStartBAP,
3 * LineLayoutManager.DEFAULT_SPACE_WIDTH,
0, new LeafPosition(this, -1), true));
The Position marked *** should be a LeafPosition(this,
vecAreaInfo.size() - 1); as it is in the element more connected with
the real space (if this element is ignored, the space is too) maybe
it is this one that must be notified.
[from your other message]
I am also unsure what the correct knuth element sequences are in
the case of the forced line break and for hyphenation.
A forced line break should not be very different from the real end
of the inline, so I think it should be enough to add a box/glue
element (according to the conditionality [1]) whose width is
lineEndBAP before the penalty. In this case, the next returned
sequence should start with the elements for the initial border and
padding.
As per the hyphenation, I think we could use the same sequence
created for a space (according to the alignment), but
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: May we assume that in that case, the first free column-number may be used (taking into account spans from previous rows)? It's not all that difficult to track pending row-spans, so we could already take care of that when determining the initial value, and it makes more sense to me to interpret it that way, but just thought I'd ask... Cheers, Andreas
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 Donaudampfschiffahrtselektrizitaetenhauptbetriebswerkbauunterbeamtengesellsc haft one can easily force hyphenation. But what about the other languages? I assume the Swiss contributors could come up with some French, Italian and Raeto-Romanisch (forget about that we don't have a hyphenation file for it) samples and there are some native English speakers around as well. For which language which is supported by a FOP/OFFO hyphenation file can we come up with the longest proper word :-)? Manuel
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 TableBorderPrecedence gave me just the hint I needed to get the necessary understanding of the property system...) Expect more later today. Still have to remove some superfluous code (the question hasColumnNumber() for instance, will become irrelevant, since every TableCell/TableColumn will have its column-number correctly set by the time layout starts, apart from repeated columns. I'm still struggling with those...) Cheers, Andreas
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 probably kick you for supporting that language. *bg* On 12.09.2005 11:48:08 Manuel Mall wrote: 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 Donaudampfschiffahrtselektrizitaetenhauptbetriebswerkbauunterbeamtengesellsc haft one can easily force hyphenation. But what about the other languages? I assume the Swiss contributors could come up with some French, Italian and Raeto-Romanisch (forget about that we don't have a hyphenation file for it) samples and there are some native English speakers around as well. For which language which is supported by a FOP/OFFO hyphenation file can we come up with the longest proper word :-)? Manuel Jeremias Maerki
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 problems while trying to remove them a couple of months ago, so this appears to be a task I still have to finish... Can they be safely removed now, or are there any other issues that need to be taken care of first? (The links to OFFO on the Hyphenation page seem to be in order...) Cheers, Andreas
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 children: is it just the max bpd of its children or is it max bpd plus any line spacing settings from its parent? Manuel On Mon, 12 Sep 2005 07:06 pm, Luca Furini wrote: 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 able to do the required calculations the Inline LM would need access to the KnuthElements of the subsequence it is suppose to construct the area for. However, what's given to it is a sequence of KnuthPositions (the standard addAreas() interface) not elements. Maybe there is no need for the InlineLM to know the elements, or for the LineLM to compute the height of each inline: the LeafNodeLM (and its subclasses) already set their areas bpd according to the font ascender and descender. So, InlineLM.addAreas() could check the bpd of its inline children after adding them, and choose the larger one, which could be smaller than the line height. Or am I missing something important? Regards Luca
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 has text area children: is it just the max bpd of its children or is it max bpd plus any line spacing settings from its parent? Oh, yes, the half-leading trait ... If I understand correctly the specs (4.5 Line areas) this line spacing must be added to the bpd of each inline area too. As it is the same for all inline areas, it could be stored into the LayoutContext by the LineLM. Regards Luca
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 this appears to be a task I still have to finish... Actually the hyphenation patterns are still build as part of FOP in the moment. Yes, because the source XMLs are still present under src/hyph. IIRC, it was the intention of removing them altogether, so users would have to download them from OFFO if needed. Cheers, Andreas
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 name them? Perhaps a new subpackage? For pdf, does it concern other files than those in the svg subpackage? Which files in the render.ps subpackage are concerned? What about the pdf library? All this is still a bit unclear in my head. In two words: please help... Vincent [1] http://marc.theaimsgroup.com/?l=fop-devm=112600990201878w=2
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 so we don't complicate this more than necessary and so we don't delay the first FOP release unnecessarily especially since XML Graphics Commons would need to be released, too, prior to making a FOP release. And Commons as still empty. :-) On 12.09.2005 15:27:03 Vincent Hennebert wrote: 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 name them? Perhaps a new subpackage? Let's identify the problem points first: PDFGraphics2D and PSGraphics2D: drawString() methods PDFDocumentGraphics2D and AbstractPSDocumentGraphics2D: font setup code The TextElementBridges and the TextPainters are no problem because they are plug-ins already and are thus optional for Batik. We can have multiple implementations of the TextBridges if necessary. Without the TextElementBridge Batik will paint all the text as shapes and thus use Java2D's font subsystem. 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 subsystem which should probably paint the text as shapes. The latter implementation can be done later when necessary as Batik paints all text through the TextBridge as far as I could see. For the DocumentGraphics2D classes can simply be subclassed to add font subsystem-specific code. PSDocumentGraphics2D and PSTranscoder can be removed entirely IMO. EPS should be enough for all cases, I think. The only use case for the PSTranscoder I can think of is for SVG Print, but that's easily done later again if someone really needs it again. ATM, don't bother changing any packages. All classes will be repackaged during the move to XML Graphics Commons. I can only see a few new classes in the existing packages. For pdf, does it concern other files than those in the svg subpackage? No. Which files in the render.ps subpackage are concerned? PSGraphics2D, AbstractPSDocumentGraphics2D, PSDocumentGraphics2D, PSTextElementBridge, PSTextPainter, AbstractPSTranscoder and PSFontUtils, I think. What about the pdf library? That's the big question mark for me. The PDF library should be made as font subsystem agnostic as much as possible, so Batik can use the PDF library without a mandatory dependency on FOrayFont. I haven't investigated any details here, yet. The same point obviously apply for the PS generation code of which mainly PSFontUtils has a reference on the font subsystem. At least, PostScript will be a lot easier to handle than PDF. All this is still a bit unclear in my head. In two words: please help... Well, I hope this helps a bit. I'll look a little more closely into the PDF library. Jeremias Maerki
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 character. So what is the correct bpd for an fo:inline which has text area children: is it just the max bpd of its children or is it max bpd plus any line spacing settings from its parent? Oh, yes, the half-leading trait ... If I understand correctly the specs (4.5 Line areas) this line spacing must be added to the bpd of each inline area too. As it is the same for all inline areas, it could be stored into the LayoutContext by the LineLM. That's were it may get messy. The children of a fo:inline are not only text areas but also other fo:inline, fo:character, fo:page-number, ... as well as a possible fo:block. For some areas added one would need to add the half-leading trait for others not, depending on what generated the area. Regards Luca Cheers Manuel
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 subsystem which should probably paint the text as shapes. The latter implementation can be done later when necessary as Batik paints all text through the TextBridge as far as I could see. For the DocumentGraphics2D classes can simply be subclassed to add font subsystem-specific code. PSDocumentGraphics2D and PSTranscoder can be removed entirely IMO. EPS should be enough for all cases, I think. The only use case for the PSTranscoder I can think of is for SVG Print, but that's easily done later again if someone really needs it again. ... What about the pdf library? That's the big question mark for me. The PDF library should be made as font subsystem agnostic as much as possible, so Batik can use the PDF library without a mandatory dependency on FOrayFont. I haven't investigated any details here, yet. The same point obviously apply for the PS generation code of which mainly PSFontUtils has a reference on the font subsystem. At least, PostScript will be a lot easier to handle than PDF. AFAICT, making the PDF library font-system-agnostic will require either 1) abstractions within it that must be implemented different ways within the package itself depending on the font system, or 2) some abstraction of the font system itself that would allow different font systems to be used by the same PDF library code, without the PDF code knowing which font system implementation it uses. Option 2 strikes me as being infinitely more sensible, and is the motivation for the axslFont interface. FWIW, the FOrayPDF package (as well as all other FOray packages) are written to the axslFont interface instead of the FOrayFont implementation. So, it is easy to avoid dependency on FOrayFont if you don't mind a dependency on axslFont. That might seem a trivial distinction. But I know of no other font system abstraction. Otherwise I would have strongly considered using it instead of creating axslFont. Don't forget that java.awt.Font can be wrapped inside any org.axsl.font.Font implementation. In fact, if it is wrapped inside, the java.awt.Font itself is exposed here: /** * If this Font has a java.awt.Font associated with it, return it. * @param consumer The [EMAIL PROTECTED] FontConsumer} implementation that is * requesting the AWT Font. * @param fontSize The font size, in millipoints. * @return The related [EMAIL PROTECTED] java.awt.Font} instance, if there is one, * otherwise null. */ public java.awt.Font getAWTFont(FontConsumer consumer, int fontSize) ; The only place I am a little concerned is in the font-configuration side of things within the FOrayFont implementation. It may be that more work is needed in font-registration to make sure that Batik gets the wrapped AWT font instead of some FreeStandingFont. Right now font-configuration can be configured to only register SystemFonts (AWT) or only register FreeStandingFonts, or to register both. If more work is needed there, I will need to rely on you guys to tell me what you need. Writing to the aXSL interface would allow a simple implementation that only created wrapped AWT fonts, if that were important. Also, it may be of interest to know that the FOrayFont implementation is pretty close to being able to marry FreeStandingFonts with SystemFonts. When configured this way, the AWT font is created from a font file on disk, using the same configuration options that allow FreeStandingFonts to be read from disk now. For those wishing to use only AWT fonts (like Batik and Folio), this allows them to then embed the font in an output document if they want to. For Java 1.3 and Java 1.4, only TTF fonts can be created this way. Java 1.5 also supports Type1 fonts. HTH. Victor Mote
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. Vincent
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 those that won't be used in the fo file. I'm a bit worried because I can't reproduce that easily with FOrayFont. All I can get is the set of fonts that were used within the document. I guess that rendering starts as soon as possible and that at the time when the file header is written out the whole document may not have been entirely parsed yet? (but the PDFRenderer only stores used fonts by making a call to FontInfo.getUsedFonts!? This also is the case in PSRenderer.stopRenderer). So the question is: is there a mean to only put used fonts when writing out a PS font dictionary? This would be cleaner anyway. I hope I'm clear. Vincent
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
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...) Expect more later today. Still have to remove some superfluous code (the question hasColumnNumber() for instance, will become irrelevant, since every TableCell/TableColumn will have its column-number correctly set by the time layout starts, apart from repeated columns. I'm still struggling with those...) Just a status-report: Will have to look again tomorrow... I'll have to dive deeper into the layout code first. Up until the FOTree, I got the column-numbers correctly assigned so far --only repeated columns will have to be handled by ColumnSetup for the time being. It seems it's going to take a little longer than I expected to make it pass all the layoutengine tests :-( Cheers, Andreas
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36625. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36625 --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 23:52 --- Created an attachment (id=16374) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16374action=view) Testcase with two pages, second page with reference-orientation=90 to swap ipd and bpd -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36625. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36625 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16374|Testcase with two pages,|Testcase description|second page with reference- | |orientation=90 to swap ipd | |and bpd | --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 23:53 --- (From update of attachment 16374) Testcase with two pages, second page with reference-orientation=90 to swap ipd and bpd -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36625. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36625 --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 23:54 --- Created an attachment (id=16375) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16375action=view) Testcase result before fix -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36625. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36625 --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 23:55 --- Created an attachment (id=16376) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16376action=view) Testcase result after fix -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=36625. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36625 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16374|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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 be to only support Base14 fonts; BTW, are these fonts well defined in the postscript standard? Or do they only exist in PDF? And a somewhat related question: how does font embedding work in postscript? I believe that it is like in PDF: embedding is not mandatory, one can simply put the font name in the file, and this will work if the corresponding font is installed on the client system. So this should almost always work for the fonts corresponding to the PDF Base14, and not always for others. Is there a font-naming convention? So, depending on the answers to the preceding questions: what do we choose? Systematic font embedding or only putting the font name? Thanks, Vincent Jeremias Maerki a écrit : 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 places. Obviously, that means loosing a lot of processing speed. PDF is in a better position because it's a random-access file format while PS is streaming. We can add the font objects to the PDF after we've already used them. On the other side, the PDF generated this way cannot be not a linearized file which allows Fast Web View. The browser always has to load the whole PDF file to display it because the cross-reference table is at the end of the file. So, even PDF has, in a way, the same problem. So you see: the problem is speed versus beauty. BTW, that was the reason why I started introducing a better resource handling with PS support, so we can later add such a mode where we write the PS file in a two-pass approach. On 12.09.2005 21:40:11 Vincent Hennebert wrote: 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 those that won't be used in the fo file. I'm a bit worried because I can't reproduce that easily with FOrayFont. All I can get is the set of fonts that were used within the document. I guess that rendering starts as soon as possible and that at the time when the file header is written out the whole document may not have been entirely parsed yet? (but the PDFRenderer only stores used fonts by making a call to FontInfo.getUsedFonts!? This also is the case in PSRenderer.stopRenderer). So the question is: is there a mean to only put used fonts when writing out a PS font dictionary? This would be cleaner anyway. I hope I'm clear. Vincent Jeremias Maerki
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 temporary solution (before implementing a two-pass approach) would be to only support Base14 fonts; Yes, that's an option, though it's not one I like very much. The other option is to create an extension element to be put as a child into the fo:declarations element and attached to the document using the new ExtensionAttachment functionality to provide a hint to the PostScript renderer which fonts are actually going to be used in the whole documents. Something like: fo:declarations ps:supplied-fontsGaramond,Garamond-Bold/ps:supplied-fonts /fo:declarations BTW, are these fonts well defined in the postscript standard? Or do they only exist in PDF? PDF was derived from PostScript, so yes, they are well-defined. And a somewhat related question: how does font embedding work in postscript? I believe that it is like in PDF: embedding is not mandatory, one can simply put the font name in the file, and this will work if the corresponding font is installed on the client system. So this should almost always work for the fonts corresponding to the PDF Base14, and not always for others. Is there a font-naming convention? Font embedding is indeed very similar to PDF and no, I don't think there is a font-naming convention that you can rely on in every case. So, depending on the answers to the preceding questions: what do we choose? Systematic font embedding or only putting the font name? If the current approach is very difficult to implement, then I think it's best to use the approach with the renderer hint. I can implement that for you if you want. Only referring to the font name will not work since we currently have to reencode each font to the WinAnsi charset. And since each PostScript page should be self-sufficient and removable, we can't do this reencoding when the font appears for the first time. I will also need to check with my client if the renderer hint approach would be acceptable. Thanks, Vincent Jeremias Maerki a écrit : 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 places. Obviously, that means loosing a lot of processing speed. PDF is in a better position because it's a random-access file format while PS is streaming. We can add the font objects to the PDF after we've already used them. On the other side, the PDF generated this way cannot be not a linearized file which allows Fast Web View. The browser always has to load the whole PDF file to display it because the cross-reference table is at the end of the file. So, even PDF has, in a way, the same problem. So you see: the problem is speed versus beauty. BTW, that was the reason why I started introducing a better resource handling with PS support, so we can later add such a mode where we write the PS file in a two-pass approach. On 12.09.2005 21:40:11 Vincent Hennebert wrote: 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 those that won't be used in the fo file. I'm a bit worried because I can't reproduce that easily with FOrayFont. All I can get is the set of fonts that were used within the document. I guess that rendering starts as soon as possible and that at the time when the file header is written out the whole document may not have been entirely parsed yet? (but the PDFRenderer only stores used fonts by making a call to FontInfo.getUsedFonts!? This also is the case in PSRenderer.stopRenderer). So the question is: is there a mean to only put used fonts when writing out a PS font dictionary? This would be cleaner anyway. I hope I'm clear. Vincent Jeremias Maerki Jeremias Maerki
