DO NOT REPLY [Bug 50574] content overflow onto second ODD page causes NullPointerException
https://issues.apache.org/bugzilla/show_bug.cgi?id=50574 Lance Knorr lancekn...@hotmail.com changed: What|Removed |Added CC|lancekn...@hotmail.com | -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: DO NOT REPLY [Bug 50590] New: function fop_exec() doesn't work in fop.js launcher
Wow, on the last day of the fourth year after I committed this script, it is proven that someone actually uses it. (I do not use it myself since I never work on MS Windows.) I have always considered JScript a much smarter solution than the shell in windows. But the world is not waiting for smart solutions. :( Simon On Sat, Jan 15, 2011 at 11:58:42AM -0500, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50590 Summary: function fop_exec() doesn't work in fop.js launcher Product: Fop Version: 1.0 Platform: PC Status: NEW Severity: minor Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: sergey...@gmail.com There is a small typo in the function fop_exec() in JScript startup file. A symbol '+' is missing there.
Re: DO NOT REPLY [Bug 50590] New: function fop_exec() doesn't work in fop.js launcher
On 17 Jan 2011, at 19:23, Simon Pepping wrote: Wow, on the last day of the fourth year after I committed this script, it is proven that someone actually uses it. :-) Same thought arose here after checking when the file was last altered... Regards, Andreas ---
DO NOT REPLY [Bug 48334] xml:base
https://issues.apache.org/bugzilla/show_bug.cgi?id=48334 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Attachment #26496|0 |1 is obsolete|| --- Comment #2 from Andreas L. Delmelle adelme...@apache.org 2011-01-17 13:53:45 EST --- Created an attachment (id=26500) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26500) slightly revised prototype Minor corrections plus some additional tests. For backward compatibility, URIProperty works such that, without xml:base, it will the yield exactly the same value as before (including the url() function call, if present). Before the patch, the src property was just parsed as a StringProperty. This causes a slight inconsistency in the resulting values, shown in the testcase. A relative URI resolved against a relative xml:base yields a normalized string representation, while in the regular case without xml:base, no resolution happens, so there we would get the value as specified in the FO source. Strictly speaking, both are equivalent, yet not identical... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48334] [PATCH] xml:base
https://issues.apache.org/bugzilla/show_bug.cgi?id=48334 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Platform|PC |All Summary|xml:base|[PATCH] xml:base OS/Version|Linux |All -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48334] [PATCH] xml:base
https://issues.apache.org/bugzilla/show_bug.cgi?id=48334 --- Comment #3 from Andreas L. Delmelle adelme...@apache.org 2011-01-17 14:17:51 EST --- Note that, apart from fo:external-graphic, the src property also applies to fo:color-profile and fo:external-document. If xml:base is set on fo:root or fo:declarations, the prototype will work for those cases as well. With only a trivial change (untested), the same could be applied to external-destination. That would allow one to create a document with a fo:block containing images from a specific website, and in the same block, specify relative URIs as external-destinations. If xml:base is set correctly, those links will then point to locations on the website the images are hosted on. Thinking more about it, it does seem like a powerful addition to being able to set a single base URI via the user-config. That case could also easily be covered by setting xml:base on the fo:root. Benefit being that the base-uri is available in the source (instead of only in a configuration that, perhaps, only exists while the source is rendered). Implementing xml:base in the user-config itself is an entirely different story, but there might be interesting use-cases for that as well. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50605] New: fop misrenders U+002D when using Type 1 fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=50605 Summary: fop misrenders U+002D when using Type 1 fonts Product: Fop Version: 1.1dev Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: fonts AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: sand...@crustytoothpaste.net I have a document that uses U+002D in a variety of situations, including the phrase troff -mx. Obviously, the U+002D should be flush against the m. However, when using fop with Nimbus Roman No9 L (the Type 1 Times equivalent from gsfonts) or URW Palladio L (the Type 1 Palatino equivalent), there is a significant gap after the U+002D. This occurs whether the font is bold or not. Hyphenation is also not relevant. The problem occurs in 1.0 (and trunk) but does not occur in 0.95. I've used the Apache git bridge to bisect the problem. For git, the problematic commit is 3b4af07609eb6f091ca110d99ba1f63b828222e1; for svn, it is 910445 (at least according to the information the bridge included). There are testcases and examples of the misrendering attached to Debian bug 610344 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610344). Since Nimbus Roman No9 L is generally the default font for Times on many Linux boxes, this misrendering will likely affect a significant number of users on Linux platforms. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50605] fop misrenders U+002D when using Type 1 fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=50605 --- Comment #1 from brian m. carlson sand...@crustytoothpaste.net 2011-01-17 17:43:44 EST --- Created an attachment (id=26501) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26501) Patch to prevent double-mapping -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50605] fop misrenders U+002D when using Type 1 fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=50605 --- Comment #2 from brian m. carlson sand...@crustytoothpaste.net 2011-01-17 17:44:29 EST --- I've narrowed down the problem to the call to overridePrimaryEncoding on line 422 of Type1FontLoader.java. Commenting this line out seems to solve the problem. This function (overridePrimaryEncoding) iterates over the set of metrics and sets a character code for each one based on the mapping passed in. However, two different characters are mapped to 0x2d: U+002D and U+2212. Of course, the metrics for U+2212 are different than those for U+002D; the former is wider than the latter. When layout occurs, the incorrect metrics are used and consequently, a gap occurs. I think the sensible thing to do here is not to map U+2212 onto U+002D. Attached is a patch that does exactly that. When we call overridePrimaryEncoding, the encoding is always a single byte. The patch creates an array of 256 elements. When we map a character to a byte value, we store the given character value into the array (indexed by the byte value) and make the mapping. Next time we have a mapping to the same byte value, we do nothing. And by nothing, I mean nothing. We do not map it onto the given byte value (because that breaks things, as I've demonstrated) and we do not map it onto -1 (because then the next glyph is rendered over the top of this one). We simply do nothing. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50605] fop misrenders U+002D when using Type 1 fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=50605 brian m. carlson sand...@crustytoothpaste.net changed: What|Removed |Added CC||sand...@crustytoothpaste.ne ||t -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
