FYI: Subversion on SF.net

Hello.

SF.net is preparing Subversion service (see 
https://sourceforge.net/support/tracker.php?aid=1341005) and since I like 
it more than CVS I filed request to be considered for Subversion Beta 
testing.

This does not mean we will switch to SVN anytime soon (they may not choose 
us or we may decide to stick with CVS).

Have a nice day.

Stepan Roh

Release warning

Hello.

Just to remind you all that first RC of version 2.0 will be created on 
Wednesday, November 9th which means that last changes will be accepted 
(and CVS will be closed) on Tuesday, November 8th.

Have a nice day.

Stepan Roh

problem with instructions and diacritics

Hi,

I'm getting strange behavior with combining diacritics at different font sizes.
I've attached an example
(U+00C2) (U+0041 + U+0302) (U+0190 + U+0302) (U+0186 + U+0302)
first at size 12, then at size 16
The diacritic isn't placed at the same spot in every size even though
there is a mark (it's higher than with a lowercase characters).
I get the same behavior with more than one diacritics above one base
character. They aren't centered on the same axis. This happens with
Sans and Serif.

--
Denis Moyogo Jacquerye --- http://home.sus.mcgill.ca/~moyogo

Re: problem with instructions and diacritics

Denis Jacquerye wrote:
> Hi,
> 
> I'm getting strange behavior with combining diacritics at different font sizes.
> I've attached an example
> (U+00C2) (U+0041 + U+0302) (U+0190 + U+0302) (U+0186 + U+0302)
> first at size 12, then at size 16
> The diacritic isn't placed at the same spot in every size even though
> there is a mark (it's higher than with a lowercase characters).
> I get the same behavior with more than one diacritics above one base
> character. They aren't centered on the same axis. This happens with
> Sans and Serif.

I can't verify this on my Gnome system, but that's probably because Pango 
doesn't support this stuff yet, right? (Anyone know the status of this? 
pango.org looks like it's under construction.)

Anyway the problem seems to be that the outline of the glyph moves around 
because of the instructions (grid-fitting), but the mark just sits there, so it 
might end up asymmetrical. I'll do some experiments and try to figure out how to 
fix this.

BTW, is it OK to look at another font, say, Times New Roman, for ideas? Of 
course I'd never think of copying actual code, but just to see the general 
technique of "how the heck do you make these things line up". There might be 
some patents or something, but of course pretty much everything I'm doing is 
covered by Apple's patents...

Keenan

double punctuation characters: dblexclam, U+2047-U+2049

Hello.  I've been a bit busy lately, but I've finished versions of the
double punctuation characters (dblexclam, uni2047, uni2048, and uni2049)
for all faces, using references to exclam and question in all except the
Sans Mono faces.  In the Sans Mono faces, I've created a thinner version
of question (thinquestion) as an unmapped character, and used references
to it instead of question, since the combinations that include a
question take up significantly more width than the limit of 1233.  A
patch adding them to the 20051105 snapshot is attached, although I'm
going to update it for CVS.  Comments?

Problem with H flag in created patches

Re: Problem with H flag in created patches

Hi.

On Sun, 6 Nov 2005, Ben Laenen wrote:

> I tried to create patches for the serif fonts, because I have another 
> set of Greek glyphs ready, but for some reason I can't create "clean" 
> patches:
>
> There are dozens of chunks like this in the patch: (this one is for 
> DejaVuSerif.sfd, but also bold and oblique are affected)
>
> <start>
>  <at>  <at>  -1127,7 +1127,7  <at>  <at> 
> StartChar: A
> Encoding: 65 65 65
> Width: 1479
> -Flags: HW
> +Flags: W
> TtfInstrs: 162
> <end>
>
> And it is always a change on the Flags line. It looks like the H flag is 
> not recognized by FontForge, and therefor lost when saving, because "HW" 
> flags are changed into "W", and "H" only lines are completely removed.

H flag means "glyph changed since last hinted". And you are right it 
behaves somewhat peculiarly. Could you write a mail to FF's mailing list 
(fontforge-devel@...)? Thank you.

Have a nice day.

Stepan Roh

Re: double punctuation characters: dblexclam, U+2047-U+2049

Hi.

On Sat, 5 Nov 2005, David Lawrence Ramsey wrote:

> Hello.  I've been a bit busy lately, but I've finished versions of the
> double punctuation characters (dblexclam, uni2047, uni2048, and uni2049)
> for all faces, using references to exclam and question in all except the
> Sans Mono faces.  In the Sans Mono faces, I've created a thinner version
> of question (thinquestion) as an unmapped character, and used references
> to it instead of question, since the combinations that include a
> question take up significantly more width than the limit of 1233.  A
> patch adding them to the 20051105 snapshot is attached, although I'm
> going to update it for CVS.  Comments?

I like it.

Have a nice day.

Stepan Roh

Re: double punctuation characters: dblexclam, U+2047-U+2049

Stepan Roh wrote:

<snip>

 > I like it.

Thank you.  It's committed then.

Patch for added Greek glyphs in Serif

Here are the patches for the last Greek glyphs in the Serif faces.

Some comments first, concerning the H flags:

On the fontforge-devel mailinglist I had some answers by George Williams, I'll 
just add his reply:

> DejaVuSerif is a truetype font. The 'H' flag is only relevant for
> PostScript hinting. A few months ago I started clearing the flag for
> truetype fonts (those with quadratic splines anyway). If you convert to
> cubic splines the flag will become relevant again and will reappear.
>
> TrueType has a somewhat similar "flag". If you make a significant change
> to a glyph (like adding or removing a point) ff will simply clear all
> the instructions.

after mailing him back the following:

> But now I know that it doesn't affect ttf font at all, I'm wondering why
> the H flags suddenly appeared in the sfd file. I guess it's because there
> were some anker points added for combining glyphs.

he replied:

> Old convention:
>         H flag was useless in tt fonts but maintained.
>         If a glyph were changed in any way, H flag was set (even if
>                  useless)
>
> So, yes, adding an anchor point would have set the H flag.
>
> New convention:
>         H flag not maintained for tt fonts.
>         H flag not set when changing tt font
>         H flag set on all glyphs when converting to cubic

So basically what he said: the H flags will always be removed with FontForge 
from now on. So now I just send the patches with the chunks that remove the H 
flag, because when I make a patch that keeps the H flag, the next person who 
works on the font after me will have the same problem.

So now the patch itself: it is made against the 2005-11-05 snapshot

in roman, bold, bold oblique and oblique:
added glyphs: U+03D0 - U+03E1; U+03F0 - U+03FF
edited glyphs: U+03B1 (alpha), U+03AC (alphatonos), U+03B3 (gamma)

only in bold
edited glyph: U+03C8 (psi): there was a small alignment error
edited glyph: U+03C7 (chi): background wasn't cleared

only in oblique:
edited glyphs: U+03AA (Iotadieresis) and U+03AB (Upsilondieresis): the 
dieresis suddenly moved to a completely wrong place

greetings
Ben Laenen