fontforge scripting change
by Kevin Fenzi
Greetings.
I took a deeper look tonight as to why one of my fonts failed in the
mass rebuild, and tracked it down.
The last version of fontforge I built, I enabled the python extensions,
thinking they were just an extra nice feature, and it was requested.
However, this has one side effect: the default scripting lang changes
to python.
In order to use old "legacy" fontforge scripts, you have to pass
fontforge '-lang=ff'.
I don't know how many other fonts hit this issue, but I thought I would
mention it here.
We could revert the python bindings being enabled, but I think this is
a nice feature our users would want, and with fontforge calling the old
scripts "legacy", I think it's what people will expect moving forward.
So, if you had a font build failure and you use a old style fontforge
script, please pass '-lang=ff' and see if that fixes things.
kevin
14 years, 9 months
Re: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)
by Roozbeh Pournader
> Chinese, Korean and Japanese fonts are an old source of pain for font
> packagers, due to:
... CJK information processing being very hard to do correctly. See
Ken Lunde's amazing 900-page tome, "CJKV Information Processing",
which recently appeared in its second edition:
http://oreilly.com/catalog/9780596514471/
> 1. the way Unicode.org decided it would be a good idea to have them
> share codepoints ("Han unification"), so CJK packagers compete with each
> other to make their pet font the default
I can't relate these two. By the same reasoning, Fraktur fonts would
compete with modern Latin fonts, Urdu fonts would compete with Arabic
fonts, and Hindi fonts would compete with Marathi fonts.
Font packagers competing with each other in pushing their fonts is not
acceptable either. If that doesn't stop, we should perhaps centralize
our fontconfig configuration files to avoid such fontconfig wars.
On a separate note, it wasn't unicode.org who decided to unify Han
characters. It was a consensus effort, supported by various national
standardization bodies, including those of China, Japan, and Korea.
Please don't spread FUD ;-) You can read about the actual history of
Han Unification here:
http://unicode.org/versions/Unicode5.0.0/appE.pdf
Roozbeh
14 years, 9 months
Fwd: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)
by Qianqian Fang
sorry, forget to cc the list
---------- Forwarded message ----------
From: Qianqian Fang <fangqq(a)gmail.com>
Date: Mon, Feb 23, 2009 at 11:40 PM
Subject: Re: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)
To: Jens Petersen <petersen(a)redhat.com>
On Mon, Feb 23, 2009 at 8:04 PM, Jens Petersen <petersen(a)redhat.com> wrote:
> ----- "AKanda" <welovebemani(a)gmail.com> wrote:
> > The last update for VLgothics "vlgothic-fonts-20090204-2.fc10.noarch"
> > is perhaps not good. (Install by yum.)
> > Since this update, the "japanese-fonts" of my system (all my sytem :
> > nautilus, openoffice, website ...) is not beautifull.
> >
> > http://forums.fedora-fr.org/viewtopic.php?id=39426
>
> What is your locale (desktop language)?
>
>
yes, I have the same question. The offending characters are the embedded
bitmaps from Uming.
> It looks like you are suffering from the Han unification issue Nicolas
> mentioned.
I am not sure. This used to happen when the local is non-CJK: the Japanese
fonts has the highest priorities, and Uming/Ukai mixed to show the rest.
>
> Jens
>
> _______________________________________________
> Fedora-fonts-list mailing list
> Fedora-fonts-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-fonts-list
>
14 years, 9 months
Fedora needs your help
by Nicolas Mailhot
Dear all,
As some of you know Fedora 11 will feature automatic font installation¹.
This is a genuinely new feature that does not try to ape what other
operating systems do and play on Linux's traditional attention to
localization and internationalization. It's a free/libre alternative to
the DRM-ed distribution channels proprietary foundries are pushing right
now².
However, awesome new installation code is not sufficient. To work well
this feature requires a large and sane font package pool to draw on. To
provide this pool the Fonts SIG has worked hard to define clear and sane
packaging guidelines last year³.
The maintainers of affected packages were notified two months ago of
needed changes⁴. However, while many reacted fast, others have still not
started looking at it⁵.
With only one month left before Fedora 11 beta it's time for others to
step up and help adapt the remaining packages. Please take a look at the
bugzilla tracker⁴, adopt an open bug, and propose spec file changes
there. Extensive documentation was written⁶ for this operation and you
do not need to be a font expert to participate.
Also, changing such a large pool of packages is never mistake-free, and
we also need testers to QA⁷ the changes. Please take a look at the
bugzilla tracker⁴, adopt a closed bug, and check the corresponding
package was converted properly.
I'm afraid we are massively short-handed right now. Please help.
_________
¹ http://fedoraproject.org/wiki/Features/AutomaticFontInstallation
² http://en.wikipedia.org/wiki/Embedded_OpenType
³ Finally ratified in January 2009, but their expected content was
public a long time before)
https://www.redhat.com/archives/fedora-devel-announce/2009-January/msg000...
⁴ https://bugzilla.redhat.com/show_bug.cgi?id=477044
⁵ http://blog.stevecoinc.com/2009/02/help.html
⁶ http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29
http://fedoraproject.org/wiki/Packaging:FontsPolicy
⁷
http://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts#How_To...
http://fedoraproject.org/wiki/Improving_existing_font_packages
--
Nicolas Mailhot
14 years, 9 months
Re: Help with licensing questions
by Stephen Hartke
[This message is supposed to continue the thread about licensing questions,
but I just subscribed to the mailing list, so I can't reply directly to
those messages.]
*
From*: Nicolas Mailhot <nicolas mailhot laposte net>*
Subject*: Re: Help with licensing questions*
Date*: Tue, 10 Feb 2009 22:39:47 +0100
> 12. The author thinking the metatype sources would require him to use
> some other license than the OFL because they look more software-ish is
> just confusing things (pretty common occurrence unfortunately). GPL-ing
> the build scripts would probably be more interesting, but a. they're
> lost and b. this would not change the font licensing at all.
I'm confused by this comment. My font Aurulent Sans is created by MetaType1
programs that look like this:
%% \--------------------------------------------------------------------
%% The letter n
%% %
%% \PICT{n}
%% \--------------------------------------------------------------------
beginfontglyph("n",ASCII("n"),.83lowwidth,lowsp_vert,lowsp_vert,xht,lowdepth);
x0=x1=leftstemloc; y0=xht; y1=0;
x2=x0; y2=.4[xht,y1];
x4=x41=x5=rightstemloc; y4=.3[xht,y1]; y5=0;
x3=.76[rt x1,lft x4]; % we choose the point to make "hump" farther to the
right so the divot is big.
% However, we have to be careful about bold fonts, so that x3 doesn't go
farther right than the left edge of x4.
top y3=top y31=xht+low_overshoot;
x31=.6[x3,x4]; y41=.75[y4,y3]; % works because the point put in is 1.75
expand_font_stroke.leftstem
(butt_end(0,1))
(z0--z1);
pen_stroke_method:=1;
expand_font_stroke.rightstem
(cut(fix_nib(join_px,join_py,prot),170)(0);
cut(extreme_angle(x4,px,x3,py,x2,.5))(1);
butt_end(last))
(z2{curl .3}..z3{right}..controls z31 and z41..z4{down}--z5);
pen_stroke_method:=0;
path P; P:=rightstem;
P:=smooth_straight_to_curve(P,5);
P:=smooth_curve_to_straight(P,2);
Fill smooth_curve(P);
Fill leftstem;
I think this is a program and very different than the MetaType1 sources for
Latin Modern and similar fonts that contain mainly just tables of data
points. In that sense, the GPL for the MetaType1 sources seems very
reasonable to me. Why do you think that it is inappropriate?
> 10. Lastly, font sources in metatype format can be non-trivial to build,
> and seem to require specific build scripts tuned to the TEX variant the
> distro ships. Building any font from metatype would probably require
> help from TEX specialists such as Jonathan Underwood.
>
> 11. In your case the author has lost those scripts, and does not intend
> to work from metatype anymore (preferring direct fontforge editing), so
> it's probably no great loss to forget the original metatype source. Just
> get him to publish an authoritative sfd version of his font, and use it
> as your source.
I have not lost the source for the MetaType1 programs, but rather for the
build scripts. As you point out, it's tricky to build MetaType1 files, and
I had created files that were particularly tuned to work with teTeX. I
don't really feel that it is advantageous to recreate these files. I would
much prefer to work on rewriting the MetaType1 programs using FontForge's
Python scripting.
Best wishes,
Stephen
14 years, 9 months
Font previewer requirements
by Nicolas Mailhot
Hi,
As several people asked recently both privately and publicly to add font
previews to different static medias (release notes, wiki pages,
packagekit info), and proposed various solutions that didn't cut it,
here are my requirements for a font preview generator. If such a utility
was available adding font previews to all the places people asked of
would probably not be too difficult.
Note that those requirements are different from the ones you want in a
dynamic context (such as a font preview application or a dynamic web
site)
A good static previewer:
1. would take a list of ttf/otf/ttc/pfa/pfc/pcf files as argument
2. would generate one small (size) standalone file from them
3. without needing any further input (even if an option to force a
specific preview text wouldn't hurt)
3. would give a good idea of the unicode coverage of the font files,
probably using pangrams for the most interesting unicode/script blocks
included in them. Wikipedia has a pangram list:
http://en.wikipedia.org/wiki/List_of_pangrams
and fontconfig in fedora-devel has a command to detect the script
coverage of a font:
$ fc-query --format ':lang=
%{lang}\n' /usr/share/fonts/gfs-theokritos/GFSTheokritos.otf
:lang=eu|fj|gv|ho|ia|id|ie|io|nds|nr|om|so|ss|st|sw|ts|vo|xh|zu
so it's just a matter of hooking one with the other (of course finding
the right heuristic is going to be tricky, and pangrams do not work for
CJK, and listing the full glyph list of a font is out of the question)
4. would generate vector shapes (probably svgz) so the preview does not
degrade on high pixel density displays.
5. would work with complex scripts such as indic, which requires using a
shaper such as pango
6. would not embed the font files themselves, or be a conversion of the
fonts to some other format, as this would result in hairy licensing
problems
7. would be reasonably fast and not have insanely big or exotic sofwtare
dependencies
If someone is interested in working on this it can probably be a fun
little project. If successful it would be used all over the place by all
the entities interested in free/open fonts (font authors, distributions,
oflb, etc)
Best regards,
--
Nicolas Mailhot
14 years, 10 months
Help with licensing questions
by Paul Lange
Hey,
I'm currently packaging up Aurulent Sans.
(http://fedoraproject.org/wiki/Hartke_Aurulent_fonts )
At the moment there are only some compiled *.otf files available.
Because of this I asked the author for sources to compile from. But the
answer is going a bit over my current horizon.
The answer I got an the question if it would be possible to provide some
sources is:
This is a tricky issue, for a couple of reasons:
First, the font is created with MetaType1. This is not
particularly easy to
install or setup. Will you be able to do that? Since my hard
drive crashed
over the summer, I lost some of the changes that I had made to
MetaType1 so
that it would run in Fedora (mainly shell scripts and the like).
At the
moment, I cannot compile the sources.
Second, I have ceased work on the MetaType1 version of Aurulent
Sans. I am
re-creating the font using Python scripting in FontForge, and I
think this
is a more promising approach. However, I don't have much time
to spend on
it, so this is definitely a long term project.
Third, it's not clear what license the source files should be
released
under. Since they are code, it seems that the GPL would be
appropriate, not
the OFL. However, it's not clear what the effect of using the
GPL would be;
certainly I'd want people to be able to directly modify and
redistribute the
"binary" font file.
So I don't have some experience with font building and need some hints
here.
Also I don't have a clear answer on the licensing question.
Regards,
Paul
14 years, 10 months
