Re: [fontforge-devel] possible bug in BDF generation, with correction

[Pierre H. <ha...@cl...>]

Le 21/11/2015 19:42, ms...@an... a écrit :
> On Sat, 21 Nov 2015, Pierre Hanser wrote:
>> when generating a BDF from a ttf font, if it's only BW with no grey
>> level, you cannot save it
> 
> Can you be much more specific about the circumstances under which this
> occurs?  I have no trouble generating BDFs from black-and-white TTF input
> using FontForge.  What steps are you following, and what font are you
> starting with?

ok

I use the simplest possible path with gui

fontforge ClanOT-Thin.otf

Element-> bitmap available -> size in pixel=23 -> ok

File -> generate -> generate -> resolution=guess -> ok

and there, I get a popup "there is no 23@0 bitmap available"

Fontforge version is current git version

I can send you the font by private mail if you need it.

>> it's enough to add 1 line in savefont.c:WriteBitmaps:
>>
>>     for ( i=0; sizes[i]!=0; ++i ) {
>>
>> +        if ((sizes[i]>>16) == 0)sizes[i] = 0x10000 | sizes[i];
>> +
>> 	for ( bdf=sf->bitmaps; bdf!=NULL &&
>> 		(bdf->pixelsize!=(sizes[i]&0xffff) || BDFDepth(bdf)!=(sizes[i]>>16));
>> 		bdf=bdf->next )
> 
> This idiom of comparing the high bits of a sizes[] entry against the
> return value of BDFDepth occurs many times throughout the FontForge code -
> so do they ALL need to be changed the same way?  Before concluding that,
> I'd like to find out how a sizes[] entry with all zeroes in the high bits
> was created in the first place.  It may not be a mistake (the all-zeros
> value may have been created on purpose for some reason), and if it is a
> mistake, the problem is most likely at that point in the code, not
> everywhere the entries are read.

understand

> 
>> another point that seems strange to me is at the beginning of the same
>> function:
>>
>>     for ( i=0; sizes[i]!=0; ++i );
>>     ff_progress_change_stages(i);
>>
>> the ';' after the for is suspicious but I've not investigated.
> 
> I think this loop is intended to search for a zero entry in the sizes[]
> array, and in that case the semicolon is not a mistake.  When the loop
> terminates, i will be the index of the zero entry.

ok
thanks for looking

-- 
	Pierre