DO NOT REPLY [Bug 50760] New: Indexed images in PDFs result in Adobe Reader crash on Macs
https://issues.apache.org/bugzilla/show_bug.cgi?id=50760 Summary: Indexed images in PDFs result in Adobe Reader crash on Macs Product: Fop Version: 1.0 Platform: Macintosh Status: NEW Severity: normal Priority: P2 Component: images AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: mike.sta...@gmail.com Created an attachment (id=26637) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26637) file needed to reproduce the problem Putting indexed images (PDFs and GIFs) result in crash of Adobe Reader on Macs when attempting to print the document. Viewing it is fine, its only when you try to print it then it crashes. Using Preview on mac is fine for both viewing and printing. Adobe Reader on other platforms works normally with same files. I don't know whether its Adobe Readers fault of FOP's problem, I just want to put out there. It's reliably reproducible and it results in crash every time. I would rather have it fixed by FOP team so I could update FOP on server and fix issue for all my Mac customers. As soon as images are replaced by a non indexed images Adobe Reader stops crashing. As the results the PDFs are larger in size. See below for FO and image files to reproduce the issue. No custom config. -- 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 44885] [PATCH] fo:inline-container implementation
https://issues.apache.org/bugzilla/show_bug.cgi?id=44885 Andreas L. Delmelle changed: What|Removed |Added Summary|fo:inline-container |[PATCH] fo:inline-container |implementation |implementation -- 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 44885] fo:inline-container implementation
https://issues.apache.org/bugzilla/show_bug.cgi?id=44885 Andreas L. Delmelle changed: What|Removed |Added Attachment #21893|0 |1 is obsolete|| --- Comment #9 from Andreas L. Delmelle 2011-02-10 18:21:04 EST --- Created an attachment (id=26636) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26636) updated patch against latest trunk New rough patch. Only confirmed that it renders the attached sample exactly the same as before. Layout unit tests all seem to be unaffected, as expected. Some checkstyle issues, I know. Definitely still far too sketchy and also generates too much overhead. I already factored out the inner breaker (which can then be shared with BlockContainerBreaker), but still... The nested/deferred algorithm should probably not be a full PageBreakingAlgorithm, and the breaker itself should provide straightforward/simplified overrides of more methods to control that BreakingAlgorithm. -- 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 50723] Incorrect text underlines position for some fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=50723 --- Comment #2 from Jeremias Maerki 2011-02-10 11:49:05 EST --- It's a bit of both actually. See my comment on TTFFile.determineAscDesc(). I've had to come up with some tricks to determine the best possible values for most fonts. But Alexander now has some fonts where this doesn't work. I've spent hours trying to improve this and I don't know if there's a better solution. If anyone has one, I'm thankful but please do extensive tests with as many fonts as possible! The part that is a FOP issue is the determination of the underline position (and thickness). We currently use a formula based on the baseline, ascender and descender. See AbstractPathOrientedRenderer.renderTextDecoration(). Some fonts (TrueType and Type 1) provide the desired position and thickness of the underline (but not strike and overline). Ideally, we would of course use that. If these values are reliable is, of course, another question again. -- 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 50483] [PATCH] Full font embedding and Subset embedding in Post Script
https://issues.apache.org/bugzilla/show_bug.cgi?id=50483 Mehdi Houshmand changed: What|Removed |Added Attachment #26597|0 |1 is obsolete|| --- Comment #10 from Mehdi Houshmand 2011-02-10 11:41:34 EST --- Created an attachment (id=26632) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26632) Patch Reverted changes to PSPainter (regression issue). Fixed lines > 255 chars without changing PSPainter very much -- 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: [VOTE] Merge FOP color branch into trunk
The color branch is now merged into Trunk: http://svn.apache.org/viewvc?rev=1069439&view=rev Phew. Now Batik... Jeremias Maerki
DO NOT REPLY [Bug 50723] Incorrect text underlines position for some fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=50723 --- Comment #1 from Peter Coppens 2011-02-10 09:55:56 EST --- Does the FOP community consider this a font issue or a FOP problem? In case it is considered a FOP issue we are willing to contribute a patch. -- 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: [VOTE] Merge FOP color branch into trunk
I've fixed the unit test errors. Thanks for running them on OpenJDK. I didn't expect color management to differ so much between Java runtimes. On 29.01.2011 21:06:58 Simon Pepping wrote: > I paid a little attention to the conditions determining the type of > ColorSpace, and came up with some questions: > > GraphicsSetProcessColor(Color color): Would it be possible to > implement and use ColorSpace.getNumComponents() instead of hard coding > the number of components here? I've changed that as per your suggestion. > GraphicsSetProcessColor.writeToStream and > PtocaBuilder.setExtendedTextColor: Ideally the data written out are > contained in the ColorSpace class instead of being contained in this > method for all types of ColorSpace; are they not? Sorry, but I don't understand what you're saying here. > These are only minor points. Apart from the junit problems signalled > in my earlier email, I am in favour of merging this work into trunk: > +1. > > Thanks for this work. > > Simon > > On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote: > > I get three failures on the color branch junit tests: > > > > java version "1.6.0_18" > > OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2) > > OpenJDK Server VM (build 16.0-b13, mixed mode) > > OS: GNU/Linux (Debian testing) > > > > [echo] Apache Ant version 1.8.0 compiled on March 11 2010 > > [echo] VM: 16.0-b13, Sun Microsystems Inc. > > > > [junit] Testcase: > > testSeparationColor(org.apache.fop.util.ColorUtilTestCase): FAILED > > [junit] expected:<255.0> but was:<250.0> > > > > [junit] Testcase: > > testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED > > [junit] expected:<255.0> but was:<253.0> > > > > [junit] Testcase: > > color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): > > FAILED > > [junit] org.custommonkey.xmlunit.Diff > > [junit] [different] Expected number of child nodes '14' but was '13' - > > comparing at > > /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to > > at > > /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] > > > > Simon > > > > On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote: > > > I've cleaned up the color branch, tweaked a few things and did some more > > > testing. I'm happy with the current state, so I'm calling for a vote to > > > merge the current FOP color branch into trunk. > > > > > > https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color > > > > > > +1 from me, obviously. > > > > > > Jeremias Maerki > > > Jeremias Maerki
