buildbot success in ASF Buildbot on fop-trunk
The Buildbot has detected a restored build on builder fop-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/fop-trunk/builds/384 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: The Nightly scheduler named 'fopNightly' triggered this build Build Source Stamp: [branch xmlgraphics/fop/trunk] HEAD Blamelist: Build succeeded! sincerely, -The Buildbot
DO NOT REPLY [Bug 51915] New: Line breaking in FOP is different from other tools, for example TLF.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51915 Bug #: 51915 Summary: Line breaking in FOP is different from other tools, for example TLF. Product: Fop Version: 1.0 Platform: PC Status: NEW Severity: normal Priority: P2 Component: pdf AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: alexey.hlyav...@duallab.com Classification: Unclassified Created attachment 27632 --> https://issues.apache.org/bugzilla/attachment.cgi?id=27632 Patch to make FOP ignoring too loose or too tight lines. We use TLF to dispose the text in the region on web-page and then we want to convert it to pdf. But in pdf document and in web-page some words are placed in different lines. I understand, that TLF and FOP use different line breaking algorithm, but maybe FOP has possibility to use more simple algorithm not to "align" the text? I offer a simple code change to make FOP ignoring too loose or too tight lines. Patch is attached. -- 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 51914] Rebecca Sharkey
https://issues.apache.org/bugzilla/show_bug.cgi?id=51914 Vincent Hennebert changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- 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 51914] New: Rebecca Sharkey
https://issues.apache.org/bugzilla/show_bug.cgi?id=51914 Bug #: 51914 Summary: Rebecca Sharkey Product: Fop Version: all Platform: PC OS/Version: Windows Server 2003 Status: NEW Severity: normal Priority: P2 Component: fonts AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: rebeccake...@yahoo.com Classification: Unclassified http://www.disegnitatuaggi.com http://www.carlettiviaggi.it -- 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: svn commit: r1177228 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: afp/fonts/CharactersetEncoder.java afp/ptoca/PtocaBuilder.java fonts/MultiByteFont.java render/java2d/InstalledFontCollect
Please, use our source code quality control tools. Simon On Thu, Sep 29, 2011 at 08:58:13AM -, spepp...@apache.org wrote: > Author: spepping > Date: Thu Sep 29 08:58:12 2011 > New Revision: 1177228 > > URL: http://svn.apache.org/viewvc?rev=1177228&view=rev > Log: > Various small fixes > > Modified: > > xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/fonts/CharactersetEncoder.java > xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/ptoca/PtocaBuilder.java > xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/MultiByteFont.java > > xmlgraphics/fop/trunk/src/java/org/apache/fop/render/java2d/InstalledFontCollection.java > > xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/PSImageHandlerGraphics2D.java
Re: Revision 1175754 introduces a findbugs error
Hi Simon, Well, obviously a unit test would be the ideal solution here, but alas... Funnily, I just checked and the method signature is correct on our branch, just a silly merge error. There is another way to ensure this doesn't happen again, by prefixing all overriding methods with "@Override". This way the compiler will throw an error if said method doesn't actually override any super class. Mehdi On 29 September 2011 09:20, Simon Pepping wrote: > I will fix it. It is a good habit to run findbugs. > > This error means that CIDFont.getDefaultWidth() is not overwritten in > MultiByteFont, and that therefore MultiByteFont.getDefaultWidth() > returns the wrong value. Can there be a test that reveals such an > error? > > Simon > > On Wed, Sep 28, 2011 at 08:53:26PM +0100, mehdi houshmand wrote: >> Hi, >> >> This is my fault, I think this was a merge conflict here, it should be >> MultiByteFont.getDefaultWidth(). >> >> My apologies. >> >> Mehdi >> >> On 28 September 2011 20:38, Simon Pepping wrote: >> > Revision 1175754 introduces a significant findbugs error: >> > >> > VERY confusing to have methods >> > org.apache.fop.fonts.MultiByteFont.getdefaultwidth() and >> > org.apache.fop.fonts.CIDFont.getDefaultWidth() >> > >> > Simon >> > >
Re: Revision 1175754 introduces a findbugs error
I will fix it. It is a good habit to run findbugs. This error means that CIDFont.getDefaultWidth() is not overwritten in MultiByteFont, and that therefore MultiByteFont.getDefaultWidth() returns the wrong value. Can there be a test that reveals such an error? Simon On Wed, Sep 28, 2011 at 08:53:26PM +0100, mehdi houshmand wrote: > Hi, > > This is my fault, I think this was a merge conflict here, it should be > MultiByteFont.getDefaultWidth(). > > My apologies. > > Mehdi > > On 28 September 2011 20:38, Simon Pepping wrote: > > Revision 1175754 introduces a significant findbugs error: > > > > VERY confusing to have methods > > org.apache.fop.fonts.MultiByteFont.getdefaultwidth() and > > org.apache.fop.fonts.CIDFont.getDefaultWidth() > > > > Simon > >
