Re: A few quick questions

On Fri, 2005-08-12 at 04:51 +0100, Roland Kay wrote:
>
> Hi Martin,
>
> Thanks for your help. Those answers will make it much easier to finalise
> the patch to #9240.
>
> > If you have evidence that the characters are being positioned in a different
> > way, I'd very much like to see it. It would be a fantastic fix if we can
> > manage it.
>
> I'm not sure about being positioned in a different way, but I certainly
> have evidence the measureString() underestimates the actual string length.
> The code for measureString() appears to fetch the width of each glyph and
> then sum them for the width of the string. I'm guessing that this neglects
> any space (kerning?) between the characters when they are actually displayed.
> Whatever the reason though, the returned value seems to be too small.
>
> Take a look at the attached screenshot. This is obtained by adding to following
> lines to the AP_Preview_Paragraph::draw() function.
>
> UT_UCS4String str= "This is an averagely long test string";
> UT_UTF8String width = UT_UTF8String_sprintf("GR_Graphics thinks the string is %d pixels wide.", m_gc->tdu(m_gc->measureString(str.ucs4_str(), 0, str.size(), NULL)));
> painter.drawChars(str.ucs4_str(), 0, str.size(), 100, 100);
> painter.drawChars(width.ucs4_str().ucs4_str(), 0, width.size(), 100, 1000);
> return;
>
> measureString() returns 140, but the actual width of the string on the
> screen is 233.
>

This is weird. As far a I can tell the windows graphics class places the
characters at exactly the same distance apart as that obtained from
measureUnremappedChar

Does anyone else have a comment?
> > Will you commit the patch to fix the names of Chinese fonts before 2.5?
>
> Do you think I should? It's quite a big fix. I worried it might introduce
> regressions if committed just before the 2.4 release.
>

I'll take another look at your patch soon...

Cheers

Martin

> Best wishes,
>
> R.
>
>
>
Received on Sat Aug 13 04:52:30 2005