On Wed, 2016-05-04 at 17:00 +0000, zyx wrote:

> On Fri, 2016-04-29 at 15:22 +0200, Josef Rokos wrote:
>> in attachment is patch for correct character spacing when using
>> TrueType fonts. Method PdfFontSimple::Init has generated array of
>> widths but for first 255 glyphs in font regardless of the actual
>> glyph
>> which depends on encoding. So there was the same issue as in Base14
>> Type1 fonts - characters with accent had incorrect spacing.
>

>     Hi,

Hi zyx, hi Josef,
> thanks for the patch. Maybe I read the code incorrectly, thus please
> correct me if I'm wrong, but it seems to me that the only changes you
> did were:

> a) place GetWidthArray() inline into PdfFontSimple::Init()

your (zyx') point a) is wrong, because (as Josef has posted already) the
method PdfFontMetricsFreetype::GetWidthArray calls FT_Load_Char which
uses a different encoding from what he'd like to use, and in his patch
the index into the Widths array is first transformed according to the
encoding of the font object, which isn't done without the patch. AFAIK
(guessing here ;-) ) FT_Load_Glyph called by the method the patch calls,

PdfFontMetricsFreetype::GetGlyphWidth( int nGlyphId ), doesn't have this
problem.

> b) forced the widths array to start with a space (ASCII 32)

> c) made the widths array not referenced by a reference
>

I'm posting because I'd like to also speak out against these changes:
b) should be left to the encoding to decide and c) is unnecessary, IMHO.
So could you, Josef, please prepare a new patch without these?
Please also include a documentation change for the mentioned GetWidthArray
method to say "This method only takes the TrueType font binary's built-in
encoding into account, not the encoding given to create a PoDoFo font object."
This documentation is located in src/doc/PdfFontMetricsFreetype.h in a
doxygen documentation comment (/** newline text newline */) before the
method's declaration.


> Otherwise the arrays should be the same, if I read the code properly.

As I've shown, they wouldn't be, for built-in encoding differing from
the one given for the font object construction (and the different glyphs
having different sizes).

Could you, zyx, please also answer this post (what you think of it)?

>     Bye,

>     zyx

Best regards, mabri

P.S. I hope can answer to the two other issues (with my patches), too,
today or tomorrow.

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Reply via email to