> The first one is about the TextRenderInfo's constructor, in which > textMatrix passed as an argument is multiplied by gs.ctm. As a result, > subTextMatrix is multiplied by gs.ctm again for every new TextRenderInfo > object created for an individual character, if I am not mistaken this > shouldn't be happening. In some cases I observed strange incorrect > characters coordinates caused by this.
Yikes- yes - this is a big problem. Sorry about that. This is why I want to get unit tests written around this. Unfortunately, I'm crazy busy with work right now, and I'm trying to slip this in a few minutes here and there. My apologies about this mistake - it's definitely a big problem and I'll get it fixed as quickly as I can. > The second problem is about character width, which i compute like this: > charTri.getDescentLine().getLength(). This method relies on getStringWidth > method, which adds character spacing to every character of the string, > including the last one. It seems to me that as a result I get the distance > from the beginning of the character to the beginning of the next one, > instead of the actual character width (this can be easily observed when > character spacing is large). I tried correcting the value returned from > getStringWidth, but it produced incorrect results because getStringWidth > is used also in PdfContentStreamProcessor to compute the distance from the > beginning of the character to the beginning of the next one. Instead I > have experimented with getUnscaledBaselineWithOffset and when I changed > this line: > > return new LineSegment(new Vector(0, yOffset, 1), new > Vector(getUnscaledWidth(), yOffset, 1)); > > to > > return new LineSegment(new Vector(0, yOffset, 1), new > Vector(getUnscaledWidth() - gs.characterSpacing * gs.horizontalScaling, > yOffset, 1)); > > the results seem to be correct. This is also a very good point. The returned TextRenderInfo should provide the baseline/etc... for *just* the character - not incorporating character or word spacing. I will also try to fix this - but I *really* could use some unit tests for this - any chance you would be willing to put together some test cases? The test framework can handle PDFs that you generate using iText physical or PDF files as input (though I do try to keep physical PDF files simple and small if at all possible). I've got an hour now before my next appointment - I will try to get these two changes taken care of ASAP. Cheers, K -- View this message in context: http://itext-general.2136553.n4.nabble.com/PdfContentStreamProcessor-not-handling-TJ-operator-correctly-maybe-tp4656117p4656396.html Sent from the iText - General mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions iText(R) is a registered trademark of 1T3XT BVBA. Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/ Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php
