Fontforge format change

Hi everyone,

The latest version of fontforge has brought some change to the sfd format.
The DejaVu SFD files and some scripts have been updated accordingly.
Please update you working version of fontforge to 20080110.

Have a good day,
Denis Moyogo Jacquerye

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Homepage screenshot aka font specimen...

Ben Laenen wrote:

> On Saturday 15 December 2007, Benjamin Esham wrote:
>>
>
>> It's been a month, and no one has said anything more about this, so
>> I've tried my hand at a type specimen.
>
> I forgot about it myself, to be honest :-p  But good to see other  
> people
> haven't forgotten. Here some suggestions then […]

I've fixed the issues listed and uploaded a new version, which is  
visible at
<http://commons.wikimedia.org/wiki/Image:DejaVu_specimen.svg>.

Cheers,
--

-- 
Benjamin D. Esham
E-mail/Jabber: bdesham <at> gmail.com | AIM bdesham128 | PGP D676BB9A
Esperanto, the international language  ☆  http://www.lernu.net

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
DejaVu-fonts mailing list
DejaVu-fonts <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dejavu-fonts

"Quantum" Fonts -- A (possibly crazy) idea from Trager

Hi, everyone,

I've decided to forward the following message which I sent to the
Unicode discussion list, to this list.

The first parts of the message are largely irrelevant to this list,
but my response to Sinnathurai Srivas' question #3 about how to fix
"rigidly fixed width" systems to handle Unicode is something I would
like to toss out to this development community, for what it is worth
...

Best -- Ed Trager

---------- Forwarded message ----------
From: Ed Trager <ed.trager <at> gmail.com>
Date: Feb 8, 2008 3:02 PM
Subject: Re: minimizing size (was Re: allocation of Georgian letters)
To: Unicode Discussion <unicode <at> unicode.org>

Hi, everyone,

Just a few brief comments on this thread:

>
> Having flown halfway around the world to talk to people who for whatever
> reasons, both valid and invalid (and not really distinguishing which is
> which on their list of concerns), are unhappy with a language encoding that
> in their view doubles or worse the amount of bytes used to store their
> language in Unicode, I can tell you that this as very real concern on some
> people's minds.

Re: "Quantum" Fonts -- A (possibly crazy) idea from Trager

I've never written a terminal, but...

A common use case for terminals is that the application and the
terminal are on totally separate machines. In order for the
application to be able to lay out boxes, lines, etc. such that the
columns align, it needs to have knowledge of how many cells a given
character is going to take.

With latin fonts, this is trivial, 1 character = 1 cell. Bi-width
isn't much worse, everything is 1 cell, except for a range of
characters which is agreed upon to be two.

As I understand your proposal, the number of cells a given character
has is font-specific, and varies even within script ranges. How is
this information going to be known by the application? Normally the
app has ~0 knowledge of the particular font used on the terminal.

-John

On 08/02/2008, Ed Trager <ed.trager <at> gmail.com> wrote:
> Hi, everyone,
>
> I've decided to forward the following message which I sent to the
> Unicode discussion list, to this list.
>
> The first parts of the message are largely irrelevant to this list,
> but my response to Sinnathurai Srivas' question #3 about how to fix
> "rigidly fixed width" systems to handle Unicode is something I would
> like to toss out to this development community, for what it is worth
> ...

Re: "Quantum" Fonts -- A (possibly crazy) idea from Trager

Hi, John,

Yes, you are largely correct: The hypothetical terminal application
would have to know the specific widths of more characters than current
terminal applications do now.

But I do not think this would have to be entirely font specific : one
could create a de facto or real standard stating, for example that
ARABIC LETTERS SHEEN and SAAD in terminal form take 2 character cells
in all "quantum" fonts.

Initially of course, there would only be one quantum font in existance
-- perhaps one based on DejaVu Mono Sans or DejaVu Mono Sans
Condensed, for example.

Over the years there have been many threads here and there on various
mailing lists regarding the problem of supporting complex scripts on
Unix-style terminals.

I suppose it is fair to say that all the *nix aficionados out there
don't want to give up the command line.  The command line is nice.  We
all like the command line.  Like many good things in life, the command
line is very unobtrusive.  To the uninformed observer, the command
line doesn't really look like anything interesting.  But once you know
what you can do with the command line, all that hidden unobtrusive
power, it is very addictive.

The only problem is that there still is no terminal that really
handles a large number of the non-Latin scripts well.  Mlterm is as
close as I have seen.  There are a huge number of applications that

Re: "Quantum" Fonts -- A (possibly crazy) idea from Trager

Hi Ed,

making a font that behaves like a quantum font wouldn't be difficult, 
but as John mentions, it's not just fonts that play a role here...

On Friday 08 February 2008, Ed Trager wrote:
> But I do not think this would have to be entirely font specific : one
> could create a de facto or real standard stating, for example that
> ARABIC LETTERS SHEEN and SAAD in terminal form take 2 character cells
> in all "quantum" fonts.

My initial thought is that that wouldn't be sufficient. You need to have 
tables for all possible substitutions as well. Like when in Arabic lam 
+ alif becomes a ligature, probably taking the width of 1 quantum, or 
when seen (س‎) is put in its initial or medial form, it only needs 1 
quantum instead of 2 for its isolated or final form. And I think it's 
much more difficult for Indic languages for example.

So the issue here is that you need to put all substitutions in the table 
here as well and just hope that your font behaves like it should 
(Arabic can get some very nice ligatures, which set would you define 
for a quantum font?)...

> Initially of course, there would only be one quantum font in
> existance -- perhaps one based on DejaVu Mono Sans or DejaVu Mono
> Sans Condensed, for example.

DejaVu Mono Sans Condensed is a font I've never heard of 

Re: "Quantum" Fonts -- A (possibly crazy) idea from Trager

Hi,

I find this "quantum font" proposal an intersting idea. And I'd like
to share my opinion from a non-Latin language user's point of view.

On Feb 9, 2008 7:51 PM, Ben Laenen <benlaenen <at> gmail.com> wrote:
>
> On Friday 08 February 2008, Ed Trager wrote:
> > But I do not think this would have to be entirely font specific : one
> > could create a de facto or real standard stating, for example that
> > ARABIC LETTERS SHEEN and SAAD in terminal form take 2 character cells
> > in all "quantum" fonts.
>
> My initial thought is that that wouldn't be sufficient. You need to have
> tables for all possible substitutions as well. Like when in Arabic lam
> + alif becomes a ligature, probably taking the width of 1 quantum, or
> when seen (س‎) is put in its initial or medial form, it only needs 1
> quantum instead of 2 for its isolated or final form. And I think it's
> much more difficult for Indic languages for example.
>
> So the issue here is that you need to put all substitutions in the table
> here as well and just hope that your font behaves like it should
> (Arabic can get some very nice ligatures, which set would you define
> for a quantum font?)...

I think we must end up with something like Pango for quantum fonts.

Caret positioning would be an issue for Indic scripts, as they are
encoded in the so-called "logical order" (as oppose to the so-called
"visual order" for Thai/Lao, which in fact appears as "logical" to

Re: "Quantum" Fonts -- A (possibly crazy) idea from Trager

Hi, Theppitak,

On Feb 10, 2008 12:47 AM, Theppitak Karoonboonyanan <thep <at> linux.thai.net> wrote:
> Hi,
>
> I find this "quantum font" proposal an intersting idea. And I'd like
> to share my opinion from a non-Latin language user's point of view.
>
> On Feb 9, 2008 7:51 PM, Ben Laenen <benlaenen <at> gmail.com> wrote:
> >
> > On Friday 08 February 2008, Ed Trager wrote:
> > > But I do not think this would have to be entirely font specific : one
> > > could create a de facto or real standard stating, for example that
> > > ARABIC LETTERS SHEEN and SAAD in terminal form take 2 character cells
> > > in all "quantum" fonts.
> >
> > My initial thought is that that wouldn't be sufficient. You need to have
> > tables for all possible substitutions as well. Like when in Arabic lam
> > + alif becomes a ligature, probably taking the width of 1 quantum, or
> > when seen (س‎) is put in its initial or medial form, it only needs 1
> > quantum instead of 2 for its isolated or final form. And I think it's
> > much more difficult for Indic languages for example.

Yes, we would need to associate a quantum width with every glyph in the font.

One thing I forgot to mention before but it is fairly obvious is that
some glyphs have a quantum width of 0 : combining diacritical marks,
THAI/LAO SARA I, II, U, UU and similar over- & under- vowels in other
Indic- and Indic-derived scripts.

incorrect strike metrics in DejaVuSansExtraLight?

Hi,

I've been looking at a bug in Firefox where some fonts are black when 
using text-decoration: line-through [1]

While debugging inside Pango, I saw that it uses the values of 
yStrikeoutSize and yStrikeoutPosition of the TrueType OS/2 table if 
available to tell Firefox where to draw the line.

These values for DejaVuSansExtraLight are respectively 11512 and 9600. 
Pango apparently considers them to be in EM coordinates, thus making the 
striking position/size outside of the EM box.

Is this a bug in the font, or is Pango incorrectly translating them?

For comparison, DejaVuSans has values of size/pos to 102/530 (however I 
see no OS2StrikeYPos/Size in the sfd file, not sure where it can find 
these values).

Sylvain

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=415715

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: "Quantum" Fonts -- A (possibly crazy) idea from Trager

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/