DO NOT REPLY [Bug 50276] NPE when using padding-left on fo:inline element and hyphenation is activated
https://issues.apache.org/bugzilla/show_bug.cgi?id=50276 --- Comment #1 from Matthias Reischenbacher 2010-11-15 15:37:17 EST --- Created an attachment (id=26300) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26300) 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.
DO NOT REPLY [Bug 50276] New: NPE when using padding-left on fo:inline element and hyphenation is activated
https://issues.apache.org/bugzilla/show_bug.cgi?id=50276 Summary: NPE when using padding-left on fo:inline element and hyphenation is activated Product: Fop Version: 1.1dev Platform: PC Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: matthias8...@gmx.at Created an attachment (id=26299) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26299) Testcase A NullPointerException occurs when nesting a fo:basic-link element inside a fo:inline element and the fo:inline element has padding-left. The error only happens if hyphenation is activated. That's the stack trace: Caused by: java.lang.NullPointerException at org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.applyChanges(InlineStackingLayoutManager.java:288) at org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.applyChanges(InlineStackingLayoutManager.java:318) at org.apache.fop.layoutmgr.inline.LineLayoutManager.processUpdates(LineLayoutManager.java:1363) at org.apache.fop.layoutmgr.inline.LineLayoutManager.findHyphenationPoints(LineLayoutManager.java:1336) at org.apache.fop.layoutmgr.inline.LineLayoutManager.findOptimalBreakingPoints(LineLayoutManager.java:804) at org.apache.fop.layoutmgr.inline.LineLayoutManager.createLineBreaks(LineLayoutManager.java:770) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:589) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:573) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:554) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:281) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:123) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:115) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:208) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:149) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:138) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:70) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:222) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:744) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:155) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:137) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:388) at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:90) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:349) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:300) ... 3 more Apparently the KnuthElement's position is null (oldElement.getPosition()). I attached a patch which adds an additional check in order to avoid the exception. This might not be a real solution, because I'm not sure if it's valid that the position is null. -- C
Re: Problem with FOP when generating a PNG
Hi Calixte, > I saw that in Java2DPainter class the fonts are scaled by 1000 when used > in drawText. In my mind you should do the same thing for drawImage. I > made some tests and all is ok for me (and my plugin). I am a little unclear why you think coordinates should be scaled in the drawImage method. I do not see anything wrong with the awt output when processing fo with a png external-graphic. Are you suggesting that the scaling, currently done elsewhere, is best done here? I am glad you fixed your plugin- I had a look at your commit but it represented a large changeset so I did not really follow it. Pete On Sat, Nov 13, 2010 at 11:31 AM, Calixte Denizet wrote: > Hi Peter, > > I looked after the scale factor in the paint method of my > Graphics2DImagePainter. When I export in pdf/ps, the scale factor is 1 > and when I export in PNG, it's 1/1000. > I saw that in Java2DPainter class the fonts are scaled by 1000 when used > in drawText. In my mind you should do the same thing for drawImage. I > made some tests and all is ok for me (and my plugin). > > What's your opinion ? > > Calixte > > Le jeudi 04 novembre 2010 à 13:09 +, Peter Hancock a écrit : >> Hi Calixte, >> >> Where you able to replicate the issue without integration with your > plugin? >> >> Pete >> >> On Thu, Nov 4, 2010 at 10:16 AM, Calixte Denizet >> wrote: >> > Le jeudi 04 novembre 2010 à 10:02 +, Peter Hancock a écrit : >> >> Hi Calixte, >> >> >> > >> > Hello Peter, >> > >> > i) git clone git://git.forge.scilab.org/jlatexmath.git >> > ii) cd jlatexmath >> > iii) ant && ant fop >> > iv) you should have the 2 files jlatexmath-0.9.4.jar, >> > jlatexmath-fop-0.9.4.jar in dist/, put them in the classpath (I put > them >> > in /usr/share/java in my Debian squeeze with sun java) >> > v) cd cd plugin/fop/examples/ >> > vi) fop -c conf.xml -fo latex.fo -pdf test.pdf works fine (thanks > for >> > that) >> > vi) fop -c conf.xml -fo latex.fo -png test.png doesn't work since > the >> > latex images are not drawn. >> > >> > Thanks a lot >> > >> > Best regards >> > >> > Calixte >> > >> > >> >> Could you please describe the steps and attach any files required > to >> >> replicate this bug independently of your plugin. >> >> If you are unable to do that and you think the bug may be in the >> >> plugin integration mechanism, we will require installation >> >> instructions for the fop plugin to proceed (maybe we jist need to > add >> >> a jar but please let us know- it was not clear from the link). >> >> >> >> Thanks, >> >> >> >> Pete >> >> >> >> On Wed, Nov 3, 2010 at 8:28 PM, Calixte Denizet >> >> wrote: >> >> > Hi all, >> >> > >> >> > I wrote a FOP plugin to handle LaTeX notation in FO document. I > use a >> >> > class which extends AbstractImageConverter and with a target > flavor >> >> > equals to ImageFlavor.GRAPHICS2D. All is ok when I convert a .fo > into a >> >> > pdf or ps, but I met problems when I tryed to convert into png: > the >> >> > latex images are not drawn... >> >> > >> >> > I have no problems with fop 0.95 (I just retryed and all is ok), > it is >> >> > only with fop 1.0 and the trunk version. >> >> > >> >> > My loaders and converters can be found here: >> >> > > http://forge.scilab.org/index.php/p/jlatexmath/source/tree/master/plugin/fop/src/org/scilab/forge/jlatexmath/fop/image/loader >> >> > >> >> > Any ideas ? >> >> > >> >> > Calixte >> >> > >> >> > >> >> > >> >> > >> > >> > >> > > > >
[GUMP@vmgump]: Project xml-fop (in module xml-fop) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project xml-fop has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 164 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-logging : unknown to *this* workspace -ERROR- Bad Dependency. Project: commons-io : unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/rss.xml - Atom: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 0915112010, vmgump.apache.org:vmgump:0915112010 Gump E-mail Identifier (unique within run) #167. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
Re: svn commit: r1034094 - in /xmlgraphics/fop/branches/Temp_TrueTypeInPostScript/src/java/org/apache/fop: fonts/truetype/TTFSubSetFile.java render/ps/PSFontUtils.java
Oh and could you also update the build.xml to use Java 5, it won't
build with 1.4 since enums weren't a part of the Java 4 spec.
On 14 November 2010 10:32, mehdi houshmand wrote:
> I attempted to build the code on my home system (Windows 7, latest
> java release 1.6.0_22) and I got the same thing. After some
> investigation it turns our this is a known bug with maven (google
> "maven enum bug"). It might be worth putting the semi-colon in there
> to prevent anyone else facing this issue since it makes little
> difference either way.
>
> Thanks
>
> Mehdi
>
> On 14 November 2010 09:17, mehdi houshmand wrote:
>> I was building from the command line, using "ant package" and
>> referencing I've got the same version as you... Curious... Though I
>> completely agree with your comments on TTFSubSetFile, it needs a
>> little sprucing.
>>
>>> Hi Mehdi
>>>
>>> On 12.11.2010 16:32:45 mehdi houshmand wrote:
Hi Jeremias,
This code fails the build, you need to add a ";" (a semi-colon) to the
last parameter in the enumerated type in
o.a.f.fonts.truetype.TTFSubSetFile.
>>>
>>> I don't see that. Eclipse/ECJ is happy with it and the Sun JDK 1.5.0_22
>>> also doesn't have a problem when running the Ant build. Checking the JLS
>>> 3.0, the semicolon is optional if there's no body content after the
>>> entries. An example from the JLS:
>>>
>>> public class Example1 {
>>>
>>> public enum Season { WINTER, SPRING, SUMMER, FALL }
>>>
>>> public static void main(String[] args) {
>>> for (Season s : Season.values()) System.out.println(s);
>>> }
>>> }
>>>
>>> What environment are you working with?
>>>
I was also curious why you made
TTFSubSetFile.GlyphHandler? Why do you make it an interface, and why
do you use an anonymous class in PSFontUtils, only to pass it back to
the same class? If there's only one implementation and if it only
contains a single method, I wouldn't have thought an interface was
necessary.
>>>
>>> It's a normal callback interface from PSFontUtils back into
>>> TTFSubSetFile, called for each glyph when building the subset.
>>>
TTFSubSetFile already contains various methods that perform
similar functions (i.e. take an input, convert it to the necessary
format and write to file), why couldn't this be implemented in the
handleGlyphSubset(...) method?
>>>
>>> My main problem with the way TTFSubSetFile is currently written is that
>>> writing the records is mixed with building the table index. If that were
>>> not so, it would have been easier to go with an approach that you would
>>> have expected. But my approach actually has the advantage that there's
>>> less memory build-up, since not the whole subset including glyphs has to
>>> be buffered in memory. After all, TTF loading is known to take a LOT of
>>> memory.
>>>
Is there another implementation you're
making this flexible for?
>>>
>>> No. The context: my client (your employer) asked for urgent help to
>>> resolve the problem with my first attempt at TTF subsets when printed on
>>> HP printers. I needed a quick resolution after I found out what could be
>>> wrong. I didn't know if I would turn out to be right until after I
>>> committed the changes and Chris/Vincent could run tests. So I didn't
>>> care about too much code beauty. There's actually quite a bit of
>>> copy/paste/change in TTFSubSetFile as a result which I'm not
>>> particularly proud of. I'm still waiting for feedback if my change
>>> really fixed the problem although preliminary results show that the
>>> problem is now solved. I expect that some refactoring would do
>>> TTFSubSetFile some good.
>>>
Also, from a design point, why have you made each glyph a single
string?
>>>
>>> That was no design decision. It's a requirement found in the PS langref
>>> third edition, page 356, describing the contents of /GlyphDirectory.
>>> Each glyph is looked up by its index when an array is used.
>>>
Surely if the string must finish at a glyph boundary, then we
could pack in several glyphs into the string and make it intelligent
enough not to write partial glyphs?
>>>
>>> That would be useful if we were to keep putting the glyphs in the /sfnts
>>> entry, but not with /GlyphDirectory.
>>>
Will this method have any performance benefits/disadvantages?
>>>
>>> The GlyphDirectory allows to keep memory consumption down in the JavaVM.
>>> Otherwise, I see no implications.
>>>
The spec says 65535 is the array limit, will this be hit?
>>>
>>> I think that's unlikely. We will hardly have any font with more than
>>> 65535 glyphs and no single glyph is likely to be larger than 64KB to
>>> describe its outline. We might still run into problems with the /sfnts
>>> entry, though. If we can improve TTFSubSetFile it should be much easier
>>> to stop strings at record boundaries.
>>>
>>>
>>>
>>> Jeremias Maerki
>>>
>>>
>>
>
