DO NOT REPLY [Bug 42748] - FOP 0.93 is not resolving empty fo:inline index markers
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=42748. 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=42748 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- 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 42144] - [PATCH] Safely set postscript page device dictionary, additional processing states for OffDocumentItems
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=42144. 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=42144 --- Additional Comments From [EMAIL PROTECTED] 2007-06-27 01:29 --- Adrian, thanks for the updated patch. Unfortunately, it seems to be incomplete. The class PSDictionary is missing and it doesn't seem to be expected in the objects package like with the previous patch. -- 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 42144] - [PATCH] Safely set postscript page device dictionary, additional processing states for OffDocumentItems
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=42144. 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=42144 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #20340|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2007-06-27 02:08 --- Created an attachment (id=20399) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20399action=view) patch file Updated patch with missing files (in my haste I forgot to add them to subversion before creating the diff). -- 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 42144] - [PATCH] Safely set postscript page device dictionary, additional processing states for OffDocumentItems
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=42144. 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=42144 --- Additional Comments From [EMAIL PROTECTED] 2007-06-27 02:11 --- Greatly reduced the dictionary object, hence the objects package now removed. -- 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: Job Change
On Jun 26, 2007, at 16:08, [EMAIL PROTECTED] wrote: Hi Richard, Please note that as of this Friday I will no longer be working at Geoquip. Any e-mail directed to [EMAIL PROTECTED] on matters concerning FOP is unlikely to get any meaningful response. Hopefully I will still get the chance to continue working on FOP and I intend to take another look at the memory usage patches asap, I'm in the process of looking at your patch right now. I suppose you've already seen the additional comment on the bug (?) So far, I'm looking in the direction of two possible causes: percentages or length-ranges (or both: percentages in/of length-ranges). If you take testcase 'block-container_content_size_percentage.xml' for example, and run it separately, you'll notice the infamous 'Cannot find LM to handle given FO for LengthBase' messages. All the other warnings are a result of this error. Still have to play with it some more first to say for sure why this happens (and to find out whether these cause all of the errors, or if a few are caused by other changes). Stay tuned. Cheers, Andreas
Character-by-character font selection strategy
I see there was a recent thread on fop-user called Mixing Languages and Unicode. I have the same problem. The PDFs that I create with FOP could potentially contain any mix of languages and no one font will support them all. I do not believe it is practical to try to implement a character-by- character font selection strategy in XSLT, even if I could figure out how to do it. Nor do I believe it is practical to try to create some custom font that supports all languages and embed that in all my PDFs. So my question is, what would it take to implement support for the font-selection-strategy property? Has anyone looked at this or taken a crack at it? Is there any chance that it might be implemented in the foreseeable future? Thanks, Loran Kary
Re: Job Change
On Jun 27, 2007, at 19:44, Andreas L Delmelle wrote: On Jun 26, 2007, at 16:08, [EMAIL PROTECTED] wrote: ... Hopefully I will still get the chance to continue working on FOP and I intend to take another look at the memory usage patches asap, I'm in the process of looking at your patch right now. I suppose you've already seen the additional comment on the bug (?) So far, I'm looking in the direction of two possible causes: percentages or length-ranges (or both: percentages in/of length- ranges). OK, I think I've found the cause. It is indeed related to percentages. If you change the example to give each property a different percentage value, the warnings all disappear. Seems to be the possible issue #2 I pointed to in my first comments in Bugzilla 41044: the 50% *cannot* be considered one and the same for all four block-containers, even less so for width and height, and that's exactly what does happen after applying the patch. OTOH, the absolute 100pt is the same one for all the block- containers and for width and height, so that's definitely going in the right direction. The keys to solving the percentage-issue: Note that percentages are never actually resolved until during layout. At the time the property is parsed/created, there is not enough context available to determine that in fact all those percentages resolve to the same absolute value later on. While it appears trivial /here/ to resolve these at parse-time, keep in mind that the base-length might as well be another percentage, and may be based on a length that is layout-dependent. AFAIU, what happens here is roughly: When the property is parsed, the percent-base of the 50% is set to the first parent block-container, and its factor to 0.5. Based on those two components, you decide to create a canonical 50%, that is used for every occurrence of the string 50% as an attribute value for a length property. For the first block-container, there are no foreseeable problems, as the percent-base that is stored in the canonical instance is really the same one, but... For the second one, the percentage-resolution mechanism climbs up the ancestry of the current layoutmanager to find the LM associated to the 50%, and doesn't find it. Cheers, Andreas
Re: Character-by-character font selection strategy
On Jun 27, 2007, at 20:49, Loran Kary wrote: Hi, I see there was a recent thread on fop-user called Mixing Languages and Unicode. I have the same problem. The PDFs that I create with FOP could potentially contain any mix of languages and no one font will support them all. I do not believe it is practical to try to implement a character-by- character font selection strategy in XSLT, even if I could figure out how to do it. Nor do I believe it is practical to try to create some custom font that supports all languages and embed that in all my PDFs. I agree. Implementing something like this in XSLT is indeed a complete waste here. As for custom fonts supporting all possible Unicode-characters, they tend to blow up the resulting PDF's size when embedded... Font-selection is precisely why --I think-- the Recommendation states that in the first step of formatting, all 'characters are converted in character FOs' (in 1.1.2 Formatting). One could even argue that FOP is not compliant to the Rec here, as it treats contiguous blocks of text in the source XML internally as one character array. So my question is, what would it take to implement support for the font-selection-strategy property? Now, /there/ is a GOOD question to ask first! 8-) Always make /us/ think about that first, before nagging about possible plans to implement. Nice strategy. I like your style. :-) Come to think of it, a little understanding of FOP's internals and the implied Java-knowledge should be enough. No need to touch the layoutengine for this, if I judge correctly. We could implement this at the point where the FOText instances are processed, since the font- family info is already available at that point (and hence, there is the possibility to check for codepoints that have no glyph). We could do a substitution to character FO's for codepoints outside the default font's mapping... Cheers Andreas
