[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    Bug#44409: Bug in the bug report
From:       Craig Drummond <cpdrummond () uklinux ! net>
Date:       2002-06-28 22:21:14
[Download RAW message or body]

On Thursday 27 June 2002 08:57, Hardy Griech wrote:
> Sorry Craig, I've mixed up two versions of the example AFM!
>
> The correct (i.e. badly generated) AFM starts with
>
> StartFontMetrics 2.0
> Comment kfontinst iso8859-15
> FontName Utopia-Bold
> FullName Utopia Bold
> FamilyName Utopia
> Weight Bold
> Notice Created with kfontinst v0.11
> ItalicAngle 0
> IsFixedPitch false
> UnderlinePosition -100
> UnderlineThickness 50
> Version 001.00
> EncodingScheme FontSpecific
> FontBBox -10158080 -16384000 81854464 60030976
> Descender -250
> Ascender 916
> StartCharMetrics 228
>

Hi,

I've just (right now...) tried the latest CVS version of kfontinst, and I get 
the following:

StartFontMetrics 2.0
Comment kfontinst iso8859-1
FontName Utopia-Bold
FullName Utopia Bold
FamilyName Utopia
Weight Bold
Notice Created with kfontinst v0.12
ItalicAngle 0
IsFixedPitch false
UnderlinePosition -100
UnderlineThickness 50
Version 001.00
EncodingScheme FontSpecific
FontBBox -155 -250 1249 916
Descender -250
Ascender 916
StartCharMetrics 228

...which looks OK. The Afm creation stuff hasn't changed in a while - so I 
don't think this is the problem. What version of FreeType do you use? I'm 
using 2.0.9 - can you recompile kfontinst against this and try? All the 
metrics are read from FreeType anyway, so I'm asuming the problem must be 
there.

I was contect about a month ago by someone else having the same problem - and 
I asked hime to try the following modification:

In FontEngine.cpp

alter the "int CFontEngine::scaleMetric(int metric)" function (on about line 
524ish...) to be:

int CFontEngine::scaleMetric(int metric)
{
    switch(itsType)
    {
        case TRUE_TYPE:
            return 
(int)(((metric*1000.0)/((double)itsFt.face->units_per_EM))+0.5);
        case TYPE_1:
            return metric && !(metric&0xFFFF) ? metric>>16 : metric;
        default:
            return 0;
    }
}


If this work let me know, and I'll put it into the source code. Basically it 
looks as if the values are being shifted by 16bits. Not sure why this is 
happening - but let me know which version of FreeType your're using, and if 
adding the above, and/or upgrading FreeType help.

Craig.

(Complete bug history is available at http://bugs.kde.org/db/44/44409.html)
[prev in list] [next in list] [prev in thread] [next in thread]