fontforge-users — Discussion area for users

[fontforge-users] Mark on Mark – fontforge not building double diacritics

[.rhavin <rh...@sh...>]

I set up Mark on Mark but fontforge is not building my glyphs correctly. 
It completely ignores the anchors in the mark. Delving into it, I found 
out that it build 1e17 from 0113 0301.

So to build 1e17 (Latin small letter e with macron and acute) it takes 
the precombined e macron version and puts an acute on to it. But it 
ignores the mark on mark on the acute (set to base) and on the macron 
(set to mark) completely.

It works if I add my top-anchor (mark on acute) to the combined glyph 
manually, but that makes the whole mark on mark feature pointless, so..

Can someone tell how this is supposed to work? Single diacritics work 
well, but the double diacritics dont.

THX!

Re: [fontforge-users] How to delete null glyph through script

[Gé v. G. <gev...@gm...>]

>Inkscape allows me to define a glyph for missing characters so I did that
and all is well now.
Great, thanks for the feedback!

>>I recommend starting with an existing working font

>I am posting this font on Github at https://github.com/NeilAgg2001/Rotator
so I worry about distribution rights for the existing font.  Do you know of
one

which is freely distributable?

You can take one of the public fonts, like Linux Libertine, Linux Biolinum
<https://en.wikipedia.org/wiki/Linux_Libertine>, etc.

But even with commercial fonts, if you remove or replace the font’s glyphs,
there’s no problem with copyright.

You need to change its name, of course, to avoid confusion, and also
because font *names *are copyright-protected, more so than a font’s
glyphs/shapes.

Re: [fontforge-users] How to delete null glyph through script

[Neil A. <ne...@pr...>]

> I recommend starting with an existing working font



I am posting this font on Github at https://github.com/NeilAgg2001/Rotator
so I worry about distribution rights for the existing font.  Do you know of
one

which is freely distributable?



> Good luck and please post an update :-)



Inkscape allows me to define a glyph for missing characters so I
did that and all is well now.



Thank you,

 Neil



--

Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com

We offer 30 year loans on single family houses!

[fontforge-users] Kerning syntax

[.rhavin <rh...@sh...>]

I'm trying to debug a font and to understand what i'm doing, I created a 
simply dummy with 4 glyphs - full simple test.sfd attached.

Then I set up a kerning lookup, put my glyphs in classes (A & B, C & D) 
and gave class C & D a kerning of -93 on class C & D. I ended up with 
this code in the sfd:


KernClass2: 3 3 "'kern' Horizontal Kerning in Latin lookup 0-1"
  3 A B
  3 C D
  3 A B
  3 C D
  0 {} 0 {} 0 {} 0 {} 0 {} 0 {} 0 {} 0 {} -93 {}


- What are those {}?
- What is '3'?

Regards, rhavin;)



full test.sfd:
_________________________________
SplineFontDB: 3.2
FontName: Untitled1
FullName: Untitled1
FamilyName: Untitled1
Weight: Regular
Copyright: Copyright (c) 2025, rhavin
UComments: "2025-12-19: Created with FontForge (http://fontforge.org)"
Version: 001.000
ItalicAngle: 0
UnderlinePosition: -100
UnderlineWidth: 50
Ascent: 800
Descent: 200
InvalidEm: 0
LayerCount: 2
Layer: 0 0 "Back" 1
Layer: 1 0 "Fore" 0
XUID: [1021 905 1659711440 14725950]
OS2Version: 0
OS2_WeightWidthSlopeOnly: 0
OS2_UseTypoMetrics: 1
CreationTime: 1766181084
ModificationTime: 1766181328
OS2TypoAscent: 0
OS2TypoAOffset: 1
OS2TypoDescent: 0
OS2TypoDOffset: 1
OS2TypoLinegap: 0
OS2WinAscent: 0
OS2WinAOffset: 1
OS2WinDescent: 0
OS2WinDOffset: 1
HheadAscent: 0
HheadAOffset: 1
HheadDescent: 0
HheadDOffset: 1
OS2Vendor: 'PfEd'
Lookup: 258 0 0 "'kern' Horizontal Kerning in Latin lookup 0" { "'kern' 
Horizontal Kerning in Latin lookup 0-1" [150,0,2] } ['kern' ('latn' 
<'dflt' > ) ]
MarkAttachClasses: 1
DEI: 91125
KernClass2: 3 3 "'kern' Horizontal Kerning in Latin lookup 0-1"
  3 A B
  3 C D
  3 A B
  3 C D
  0 {} 0 {} 0 {} 0 {} 0 {} 0 {} 0 {} 0 {} -93 {}
Encoding: ISO8859-1
UnicodeInterp: none
NameList: AGL For New Fonts
DisplaySize: -48
AntiAlias: 1
FitToEm: 0
WinInfo: 63 21 9
BeginPrivate: 0
EndPrivate
BeginChars: 256 4

StartChar: A
Encoding: 65 65 0
Width: 1000
HStem: 0 21G<0 1000> 780 20G<0 1000>
LayerCount: 2
Fore
SplineSet
0 800 m 1
  1000 800 l 1
  1000 0 l 1
  0 0 l 1
  0 800 l 1
EndSplineSet
EndChar

StartChar: B
Encoding: 66 66 1
Width: 1000
Flags: HW
LayerCount: 2
Fore
SplineSet
0 800 m 1
  1000 800 l 1
  1000 0 l 1
  0 0 l 1
  0 800 l 1
EndSplineSet
EndChar

StartChar: C
Encoding: 67 67 2
Width: 1000
Flags: W
HStem: 0 21G<0 902.5> 780 20G<97.5 1000>
LayerCount: 2
Fore
SplineSet
100 800 m 1
  1000 800 l 1
  900 0 l 5
  0 0 l 1
  100 800 l 1
EndSplineSet
EndChar

StartChar: D
Encoding: 68 68 3
Width: 1000
Flags: W
HStem: 0 21G<0 902.5> 780 20G<97.5 1000>
LayerCount: 2
Fore
SplineSet
100 800 m 1
  1000 800 l 1
  900 0 l 5
  0 0 l 1
  100 800 l 1
EndSplineSet
EndChar
EndChars
EndSplineFont

Re: [fontforge-users] How to delete null glyph through script

[Gé v. G. <gev...@gm...>]

Microsoft has its own ideas of when a font is complete enough for certain
uses.
E.g. LF and/or CR may not be defined in your font, and so MS Word replaces
them by a "notdef" box it takes from somewhere.

Therefore, I recommend starting with an existing working font, because in
it, such "hidden" but important characters are already in place.
Then put in your glyphs instead of the original ones; you can blank any
remaining original glyphs.

I don’t understand what you wrote about putting control characters in
Inkscape?
All you need – I think – is that U+000A and U+000D slots in Fontforge
should not be undefined.
So as an alternative to modifying an existing font, you could try putting
one anchor point into those two characters, so they are blank, but not
undefined.

I’m no expert, so take all this with a grain of salt.
Good luck and please post an update :-)

Gé

On Fri, Dec 19, 2025 at 6:38 PM Neil Aggarwal <ne...@pr...>
wrote:

> > recommend determining what character is missing a code point in your
> font
>
> > that Word is looking for and add it to your font instead.
>
>
>
> It looks like Word is trying to put some kind of marker at the end of
> each paragraph, see the attached test file.
>
>
>
> I put a glyph for the paragraph mark in my font, see attached.
>
>
>
> Searching online, it looks like it might be CR or LF, but I am not
> sure how to put control characters in Inkscape.
>
>
>
> Any ideas?
>
>
>
> Thank you,
>
>  Neil
>
>
>
> --
>
> Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com
>
> We offer 30 year loans on single family houses!
> _______________________________________________
> fontforge-users mailing list
> fon...@li...
> https://lists.sourceforge.net/lists/listinfo/fontforge-users
> http://fontforge.10959.n7.nabble.com/User-f8781.html
>

Re: [fontforge-users] How to delete null glyph through script

[Neil A. <ne...@pr...>]

> recommend determining what character is missing a code point in your font

> that Word is looking for and add it to your font instead.



It looks like Word is trying to put some kind of marker at the end of
each paragraph, see the attached test file.



I put a glyph for the paragraph mark in my font, see attached.



Searching online, it looks like it might be CR or LF, but I am not
sure how to put control characters in Inkscape.



Any ideas?



Thank you,

 Neil



--

Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com

We offer 30 year loans on single family houses!

Re: [fontforge-users] How to delete null glyph through script

[Abraham L. <tis...@gm...>]

Hi, Neil!

I’m a bit confused. The notdef character is critical to have in a font as
it shows when an expected character is not present in your font. I do not
generally recommend removing it, but do as you will. Instead, I would
recommend determining what character is missing a code point in your font
that Word is looking for and add it to your font instead.

You can always make the notdef character completely blank with no lines on
it and only a defined width.

Best of luck,
Abraham



On Thu, Dec 18, 2025 at 9:40 PM Neil Aggarwal <ne...@pr...>
wrote:

> Hello:
>
> I created a font using Inkscape's SVG Font Editor.
>
> When I load the font into FontForge, it has a ".notdef" glyph,
> see the attached pic.
>
> If I don't remove that glyph from the font, Word has a box at the end
> of each line.  If I remove it, everything works fine.
>
> I tried to remove that glyph via a script:
> #!/usr/bin/env python
> import fontforge
> import sys
>
> font = fontforge.open(sys.argv[1])
> font.removeGlyph(".notdef")
> font.generate(sys.argv[2]+".ttf")
> font.generate(sys.argv[2]+".otf")
> font.close()
>
> but that did not work.
>
> Any idea how to do this?
>
> Thank you,
>   Neil
>
> --
> Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com
> We offer 30 year loans on single family houses!
> _______________________________________________
> fontforge-users mailing list
> fon...@li...
> https://lists.sourceforge.net/lists/listinfo/fontforge-users
> http://fontforge.10959.n7.nabble.com/User-f8781.html

[fontforge-users] How to delete null glyph through script

[Neil A. <ne...@pr...>]

Hello:

I created a font using Inkscape's SVG Font Editor.

When I load the font into FontForge, it has a ".notdef" glyph,
see the attached pic.

If I don't remove that glyph from the font, Word has a box at the end
of each line.  If I remove it, everything works fine.

I tried to remove that glyph via a script:
#!/usr/bin/env python
import fontforge
import sys

font = fontforge.open(sys.argv[1])
font.removeGlyph(".notdef")
font.generate(sys.argv[2]+".ttf")
font.generate(sys.argv[2]+".otf")
font.close()

but that did not work.

Any idea how to do this?

Thank you,
  Neil

--
Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com
We offer 30 year loans on single family houses!

Re: [fontforge-users] fontforge scripting langage support?

[Marc C. <mc...@un...>]

hello,

On Thu, Nov 13, 2025 at 08:55:12PM -0500, ms...@an... wrote:
> This is another one where I didn't see the original message from Frank,

https://sourceforge.net/p/fontforge/mailman/fontforge-users/thread/CANkSbhqZNANJpgO%2BPs2gOjnYXSC24QCBw8qnA2QWBYdFNoeYCA%40mail.gmail.com/#msg59259427

> Anyway, I've explained why, about ten years ago, I created FontAnvil.
> I'm not sure there's much point my trying to justify that decision further
> now.  It's not necessary for anyone else but me to find it useful.

Everything is clear to me.

also: I looked more closely to the debian package and saw that it comes
with a python dependency so I will have to explore the compilation
flags.

Many thanks to all of you for your interesting and detailed anwsers.

-- 
Marc Chantreux

Re: [fontforge-users] fontforge scripting langage support?

[<ms...@an...>]

On Fri, 14 Nov 2025, Marc Chantreux wrote:
> On Thu, Nov 13, 2025 at 12:28:17PM -0600, Frank Trampe wrote:
> >    Since I never made the formal announcement, it is worth noting here that
> >    Maxim took over as maintainer of the project earlier this year. During my

This is another one where I didn't see the original message from Frank,
only Marc's reply.  It seems only about half the messages sent to the list
are arriving in my mailbox.

Anyway, I've explained why, about ten years ago, I created FontAnvil.
I'm not sure there's much point my trying to justify that decision further
now.  It's not necessary for anyone else but me to find it useful.

-- 
Matthew Skala
ms...@an...                 People before tribes.
https://ansuz.sooke.bc.ca/

Re: [fontforge-users] fontforge scripting langage support?

[Marc C. <mc...@un...>]

hello,

On Thu, Nov 13, 2025 at 12:28:17PM -0600, Frank Trampe wrote:
>    Since I never made the formal announcement, it is worth noting here that
>    Maxim took over as maintainer of the project earlier this year. During my
>    time in the maintainer role, I tried very hard to avoid breaking existing
>    workflows, and Maxim is doing the same thing.
>    Unless we hear that nobody in the world uses the FontForge scripting
>    language anymore, we are unlikely to remove it. And we will certainly
>    accept bugfix pull requests.

thank you so much for to confirm it. that was my question.

and as I say: the debian team already did the job to expurge the parts
of ff that are useless in my case.

>    collab was a bit more eligible for removal due to its alienness and

I don't even know collab so no worry here :)

regards,

-- 
Marc Chantreux

Re: [fontforge-users] fontforge scripting langage support?

[Marc C. <mc...@un...>]

hello,

On Thu, Nov 13, 2025 at 12:11:05PM -0500, ms...@an... wrote:
> > Did you step up for the maintenance of the ff langage? removing a
> > feature is something you only do for real reasons like "no one is
> > interested in the maintenance of this feature anymore".
> I'm not sure what you mean there.

OK. I'm sorry about my english but don't worry: you replied anyway.

AFAI understand, the best scenario is contribute to the ff code base to
be sure that:

* the ff scripting langage is still working
* there is a way to compile ff as a cli tool for font conversion
  (ie w/o support of GUI, networking, printing and python). AFAI
  understand, that's what the debian fontforge-nox package does (nox
  means "no X window" so no GUI).

> Removing them completely.  Especially bearing in mind FontForge's uneasy
> relationship with the Autotools build system, keeping the "option up and
> working" was not a realistic possibility.

I don't get it: To me that's the whole point of autotools: testing
for the .h presence to activate/desactivate compilation options by
default when you are not explicitly using options so if ff already use
it, that's very good.

> Then users can have the choice of having that feature set or not, by
> choosing between FontAnvil and FontForge, not by passing an option to the
> FontAnvil build.

well ... fontanvil looks like the fontforge-nox debian package, the
difference is:

> Keeping as close as possible to the mainline wasn't my goal - if I wanted
> that, I would have just kept using the mainline - and with the likely
> demise of the native scripting language it would become even less important.

So you can't use the work made by the community.

I read the message from Frank Trampe so I'll try to bugfix ff scripting
langage by myself whenever it will be broken.

regards,

-- 
Marc Chantreux

Re: [fontforge-users] fontforge scripting langage support?

[Frank T. <fra...@gm...>]

Since I never made the formal announcement, it is worth noting here that
Maxim took over as maintainer of the project earlier this year. During my
time in the maintainer role, I tried very hard to avoid breaking existing
workflows, and Maxim is doing the same thing.

Unless we hear that nobody in the world uses the FontForge scripting
language anymore, we are unlikely to remove it. And we will certainly
accept bugfix pull requests.

collab was a bit more eligible for removal due to its alienness and
overhead and the probability that nobody in the world used it due to its
main proponent (still generally supportive and on our governing board)
switching to a different environment for the work collab was intended to
support. We got no complaints.


On Thu, Nov 13, 2025 at 9:16 AM Maxim Iorsh via fontforge-users <
fon...@li...> wrote:

> Hey Marc,
>
> The current situation is more or less as follows:
>
> The use of legacy FF scripting is discouraged, and bug reports will
> probably be ignored. I don't think it will be ever removed, because people
> do use it. I'm generally OK with accepting new features as long as they do
> not supersede the Python capabilities. It means that if something is
> available in Python, feel free to add it to a legacy script too. Otherwise,
> make that something available in both Python and legacy scripting.
>
> Regarding your questions. FF C API should not be considered stable. We are
> sort of trying to keep it intact, but the last libfontforge release was in
> 2019, and there are no plans to make new releases or to formally preserve
> the 2019 API. I wouldn't go for yet another language binding, it would be
> just a lot of boring maintenance - FontForge is quite a big thing, and the
> API is extensive.
>
> I'm taking the liberty to speak about the future in a very determined
> manner, but no obligations here.
>
> Best regards,
>  -- Maxim.
> <https://kishkush.net/@iorsh>
>
>
> On Thu, 13 Nov 2025 at 16:47, Marc Chantreux <mc...@un...> wrote:
>
>> hello fontforge,
>>
>> Some members of [katzele](http://katzele.netlib.re/)
>> and [PPP](https://prepostprint.org/) ran a joint
>> hackathon this week end and we talked about a script
>> using [phosphor](https://gitlab.com/emilegreis/phosphor)
>> which is based on ff.
>>
>> As we try to keep the global codebase as minimal as possible,
>> python is a dependency we want to avoid in our projects.
>>
>> As I already used ff to export ttf fonts to groff, I I talked about how
>> *underrated* the ff langage is (support of argv, filename modifiers,
>> ...) and the syntax is ok compared to the python one for the simple task
>> we have to program. So I suggested we can compile ff wo python and gui
>> supportl and someone opposed that ff script may be unmaintained and could
>> be
>> removed at some point.
>>
>> I read the [doc](https://fontforge.org/docs/scripting/scripting.html)
>> and confirm it's called "a legacy language" but what "legacy"
>> means from the maintainance perspective? would it be removed? are new
>> features accepted?
>>
>> So I have 2 questions:
>>
>> * how clean is the ff API? I mean: how hard would it
>>   be to create a binding for tiny langages like
>>   [jim](https://jim.tcl.tk/home/doc/www/www/index.html)
>>   [lua](https://www.lua.org/) or any lightweigtht scheme interpreter?
>> * if a binding is hard, is it safe to use the ff langage?
>>
>> thanks for any help and regards
>>
>> --
>> Marc Chantreux
>> _______________________________________________
>> fontforge-users mailing list
>> fon...@li...
>> https://lists.sourceforge.net/lists/listinfo/fontforge-users
>> http://fontforge.10959.n7.nabble.com/User-f8781.html
>
> _______________________________________________
> fontforge-users mailing list
> fon...@li...
> https://lists.sourceforge.net/lists/listinfo/fontforge-users
> http://fontforge.10959.n7.nabble.com/User-f8781.html

Re: [fontforge-users] fontforge scripting langage support?

[<ms...@an...>]

On Thu, 13 Nov 2025, Marc Chantreux wrote:

> > So I forked FontForge in the mid-2010s, creating something I called
> > FontAnvil, which was intended to be a standalone interpreter of the
> > FontForge scripting language.
>
> Did you step up for the maintenance of the ff langage? removing a
> feature is something you only do for real reasons like "no one is
> interested in the maintenance of this feature anymore".

I'm not sure what you mean there.  I was concerned that mainline FontForge
would likely remove the native scripting language.  All questions and
issues with it, at the time, were being answered with "use Python
instead."  I didn't want to use Python instead, so I wanted to make sure I
would continue to have something I could use if FontForge did remove
native scripting.

> I don't have a lot of experience in ff but phosphor is the first
> code I see using the python binding. Every other ff code I read
> are shell scripts using fontforge -c or poorly writen (meaning not
> taking advantages of the features of the langage) ff scripts.

Yes, it seems to me that both at the time and now, there was demand for
the native scripting language.  I mean, I wanted to use it myself, which
was the reason for my involvement.  But the FontForge development team
didn't want to maintain it.  They wanted to treat Python as "the" way of
scripting the package - as shown for instance in the insistence on using
the word "legacy."

I was for a long time on the list as part of the mainline FontForge
"development team" myself; but it seemed to make more sense to me to spin
my script-interpreter work into a separate package rather than just
maintaining it within mainline FontForge.

The GUI, networking, and printing feature sets are not harmless in the
context of a script interpreter that doesn't use them.  They make the
package much larger, they add massive dependencies, and being OS-specific,
they greatly increase the effort to test and maintain the package on
different platforms.  Someone who only needs the script interpreter
benefits from having a package without those feature sets, not only just
leaving them unused.  This argues for a separate package, not just
maintaining the script language within mainline FontForge.

> > mentioned further.  On the tech side, I was hoping to improve stability
> > and reduce dependencies by eliminating the networking, printing, and GUI
> > feature sets, each of which is huge, non-core, and an obstacle to
> > portability.
>
> Removing them completly or keep the compiling option up and working?
> That would have been my strategy to stay as close as possible to the
> mainstream.

Removing them completely.  Especially bearing in mind FontForge's uneasy
relationship with the Autotools build system, keeping the "option up and
working" was not a realistic possibility.

The mere presence of something like "collab" in the code base, for
instance, adds many dependencies and a massive maintenance load for
building on different systems, and it touches every part of the system
that touches the font data at all, so making it a conditional compilation
choice means a huge number of conditionals.  You can't just leave it in
place as benign neglect while working on something else, because every
change to anything collab touches, entails maintaining the collab code
too.  You must either commit to spending a huge amount of developer time
on the ongoing costs of collab, or *remove* it - which is a significant
cost up-front but then saves time ever after.  I chose to remove it.

Then users can have the choice of having that feature set or not, by
choosing between FontAnvil and FontForge, not by passing an option to the
FontAnvil build.

Keeping as close as possible to the mainline wasn't my goal - if I wanted
that, I would have just kept using the mainline - and with the likely
demise of the native scripting language it would become even less
important.

-- 
Matthew Skala
ms...@an...                 People before tribes.
https://ansuz.sooke.bc.ca/

Re: [fontforge-users] please take me off the mailing list

[Marc C. <mc...@un...>]

You just have to follow the List-Unsubscribe link available in the
header of any message sent from this list.

regards,

-- 
Marc Chantreux

Re: [fontforge-users] fontforge scripting langage support?

[<ms...@an...>]

On Thu, 13 Nov 2025, Maxim Iorsh via fontforge-users wrote:

> The current situation is more or less as follows:

I don't see the original message for this.  Maybe it wasn't sent to the
list?  Anyway:

I use FontForge scripting in the Tsukurimashou Project,
  https://tsukurimashou.org/

Years ago it became clear that FontForge wasn't going to continue
supporting its own scripting language and was pushing everyone to use
Python instead.  I wasn't willing to switch to Python, and between that
and other changes being made to FontForge, I was concerned that FontForge
would become unsuitable for my purposes.

So I forked FontForge in the mid-2010s, creating something I called
FontAnvil, which was intended to be a standalone interpreter of the
FontForge scripting language.  The idea was that FontAnvil would remain
usable for my project even if FontForge dropped support for its own
scripting language, or made other changes that made FontForge unsuitable
for me - as seemed likely at the time.  I also had some concerns about
possible politcal stands that might be taken by the FontForge project,
which fortunately didn't materialize and so probably don't need to be
mentioned further.  On the tech side, I was hoping to improve stability
and reduce dependencies by eliminating the networking, printing, and GUI
feature sets, each of which is huge, non-core, and an obstacle to
portability.

I have not been active in FontForge development basically since that era,
but if you dig far enough back in the mailing list archive you can
probably get a good idea of the technical perspective behind FontAnvil.

> The use of legacy FF scripting is discouraged, and bug reports will probably
> be ignored. I don't think it will be ever removed, because people do use it.

On the contrary, I thought the writing was on the wall for FontForge
native scripting even as far back as 2016, and in fact I'm surprised it
hasn't already been eliminated by now; the push to Python was in effect
long ago.

Anyway, FontAnvil still exists, and is here:
   https://tsukurimashou.org/fontanvil.php.en

That may be of some interest to Marc because it sounds like we have
similar use cases.

However, I haven't touched FontAnvil in a number of years.  I basically
got it to the level I needed for my own use and then (not seeing a
groundswell of support or interest from anyone other than myself) I left
it at that.  Some aspects of the package are both rough and undocumented,
a couple of significant technical challenges that don't absolutely need to
be solved, haven't been, and if there were any relevant updates to
FontForge since the point where I branched off, they haven't been
incorporated.  I believe it still compiles on reasonably recent Linux
because I have a cron job that does that, but I haven't even looked
closely at the output of that to make sure it's all good.

My own career path has made it very difficult for me to work on the
Tsukurimashou Project at all, even though I still hope to bring *that* to
some kind of completion in the next few years; and my available time for
FontAnvil is now basically limited to keeping it in a state where it works
for Tsukurimashou, because FontAnvil is not the main focus of my project.

-- 
Matthew Skala
ms...@an...                 People before tribes.
https://ansuz.sooke.bc.ca/

[fontforge-users] please take me off the mailing list

[Kristen <kri...@gm...>]

Re: [fontforge-users] fontforge scripting langage support?

[Marc C. <mc...@un...>]

hello Matthew,

> So I forked FontForge in the mid-2010s, creating something I called
> FontAnvil, which was intended to be a standalone interpreter of the
> FontForge scripting language.

Did you step up for the maintenance of the ff langage? removing a
feature is something you only do for real reasons like "no one is
interested in the maintenance of this feature anymore".

I don't have a lot of experience in ff but phosphor is the first
code I see using the python binding. Every other ff code I read
are shell scripts using fontforge -c or poorly writen (meaning not
taking advantages of the features of the langage) ff scripts.

> mentioned further.  On the tech side, I was hoping to improve stability
> and reduce dependencies by eliminating the networking, printing, and GUI
> feature sets, each of which is huge, non-core, and an obstacle to
> portability.

Removing them completly or keep the compiling option up and working?
That would have been my strategy to stay as close as possible to the
mainstream.

regards,
-- 
Marc Chantreux

Re: [fontforge-users] fontforge scripting langage support?

[Marc C. <mc...@un...>]

Hi Maxim,

Thanks for such a fast and detailed anwser.

On Thu, Nov 13, 2025 at 05:13:51PM +0200, Maxim Iorsh via fontforge-users wrote:
>    Hey Marc,
>    The current situation is more or less as follows:
>    The use of legacy FF scripting is discouraged, and bug reports will
>    probably be ignored.

Including maintenance patches? I mean: I wouldn't came to this list to
ask for extra work to the maintainer of the project. I'm just evaluating
the possible risk of me maintaining the part of ff I need for the
equivalent of phosphor to work and choose a strategy.

If this strategy is to go for the ff langage, patches that should work
for me should work for you so why not merging them? (at least after a
while when usage proven it actually works for us).

The only thing that can screw me is you deciding to implement this part
of the API in a non-bindable langage (like python, go ...). Aside, it's
just asking how hard the maintenance could be.

> I'm taking the liberty to speak about the future in a very determined
> manner, but no obligations here.

loud and clear Sir! thank you so much for this and for ff in general
(in average, I used it once a century but it worked fine and was really
convenient to use).

Regards!

-- 
Marc Chantreux
Pôle CESAR (Calcul et services avancés à la recherche)
Université de Strasbourg
14 rue René Descartes,
BP 80010, 67084 STRASBOURG CEDEX
03.68.85.60.79

Re: [fontforge-users] fontforge scripting langage support?

[Maxim I. <io...@us...>]

Hey Marc,

The current situation is more or less as follows:

The use of legacy FF scripting is discouraged, and bug reports will
probably be ignored. I don't think it will be ever removed, because people
do use it. I'm generally OK with accepting new features as long as they do
not supersede the Python capabilities. It means that if something is
available in Python, feel free to add it to a legacy script too. Otherwise,
make that something available in both Python and legacy scripting.

Regarding your questions. FF C API should not be considered stable. We are
sort of trying to keep it intact, but the last libfontforge release was in
2019, and there are no plans to make new releases or to formally preserve
the 2019 API. I wouldn't go for yet another language binding, it would be
just a lot of boring maintenance - FontForge is quite a big thing, and the
API is extensive.

I'm taking the liberty to speak about the future in a very determined
manner, but no obligations here.

Best regards,
 -- Maxim.
<https://kishkush.net/@iorsh>


On Thu, 13 Nov 2025 at 16:47, Marc Chantreux <mc...@un...> wrote:

> hello fontforge,
>
> Some members of [katzele](http://katzele.netlib.re/)
> and [PPP](https://prepostprint.org/) ran a joint
> hackathon this week end and we talked about a script
> using [phosphor](https://gitlab.com/emilegreis/phosphor)
> which is based on ff.
>
> As we try to keep the global codebase as minimal as possible,
> python is a dependency we want to avoid in our projects.
>
> As I already used ff to export ttf fonts to groff, I I talked about how
> *underrated* the ff langage is (support of argv, filename modifiers,
> ...) and the syntax is ok compared to the python one for the simple task
> we have to program. So I suggested we can compile ff wo python and gui
> supportl and someone opposed that ff script may be unmaintained and could
> be
> removed at some point.
>
> I read the [doc](https://fontforge.org/docs/scripting/scripting.html)
> and confirm it's called "a legacy language" but what "legacy"
> means from the maintainance perspective? would it be removed? are new
> features accepted?
>
> So I have 2 questions:
>
> * how clean is the ff API? I mean: how hard would it
>   be to create a binding for tiny langages like
>   [jim](https://jim.tcl.tk/home/doc/www/www/index.html)
>   [lua](https://www.lua.org/) or any lightweigtht scheme interpreter?
> * if a binding is hard, is it safe to use the ff langage?
>
> thanks for any help and regards
>
> --
> Marc Chantreux
> _______________________________________________
> fontforge-users mailing list
> fon...@li...
> https://lists.sourceforge.net/lists/listinfo/fontforge-users
> http://fontforge.10959.n7.nabble.com/User-f8781.html

[fontforge-users] fontforge scripting langage support?

[Marc C. <mc...@un...>]

hello fontforge,

Some members of [katzele](http://katzele.netlib.re/)
and [PPP](https://prepostprint.org/) ran a joint
hackathon this week end and we talked about a script
using [phosphor](https://gitlab.com/emilegreis/phosphor)
which is based on ff.

As we try to keep the global codebase as minimal as possible,
python is a dependency we want to avoid in our projects.

As I already used ff to export ttf fonts to groff, I I talked about how
*underrated* the ff langage is (support of argv, filename modifiers,
...) and the syntax is ok compared to the python one for the simple task
we have to program. So I suggested we can compile ff wo python and gui
supportl and someone opposed that ff script may be unmaintained and could be
removed at some point.

I read the [doc](https://fontforge.org/docs/scripting/scripting.html)
and confirm it's called "a legacy language" but what "legacy"
means from the maintainance perspective? would it be removed? are new
features accepted?

So I have 2 questions:

* how clean is the ff API? I mean: how hard would it
  be to create a binding for tiny langages like
  [jim](https://jim.tcl.tk/home/doc/www/www/index.html)
  [lua](https://www.lua.org/) or any lightweigtht scheme interpreter?
* if a binding is hard, is it safe to use the ff langage?

thanks for any help and regards

-- 
Marc Chantreux

[fontforge-users] Proposal to Remove Direct X11 Support

[Frank T. <fra...@gm...>]

Hello, all.

FontForge has supported GDK for some time, and there are considerable
difficulties in maintaining the legacy X11 interface. We are considering
removing it and mandating GDK and Cairo. FontForge can still run in X11
through GDK even without the direct X11 interface. Downstream packagers and
distributors may need to adjust scripts and other packaging. Discussion is
currently on pull request #5612
<https://github.com/fontforge/fontforge/pull/5612> on GitHub. We would
normally offer a lengthy deprecation window, and we will do so if there is
a compelling reason, but a lot of the work is already done, and we would
like to move quickly if there are no deal-breakers.

Best wishes,

Frank

Re: [fontforge-users] Unicode Glyphs not shown in Windows 10

[Zsigri G. <zs...@gm...>]

Where in Windows are they not shown? I can see them in Microsoft 365 Word.

.rhavin Grobert via fontforge-users <fon...@li...>
ezt írta (időpont: 2025. jún. 25., Sze, 18:50):

> I have this Font (see attachment) and the glyphs E25D, E25F, E27D, E27F
> are shown in fontforge but when I install the font in Windows, they are not
> shown. All others are there.
> Can anyone tell me why this happens?
> Best regards, rhavin

Re: [fontforge-users] Unicode Glyphs not shown in Windows 10

[David de B. <on...@dd...>]

I'm sorry, in my test I described 'FontForge activation'. That had to be 
*FontBase*, a font manager that shows it all, but (de)activates a single 
font or it's full family on the fly, instead of OS-central installs or 
deinstalls, shows a typeface family and it's different fonts. That way 
only what you need is loaded into memory.

David

Op 27-06-2025 om 18:32 schreef David de Beer:
> As the Apple result was positive, seeing it all, I tested on both 
> LinuxMint/Debian via FontBase activation and Windows10 on both 
> FontForge activation and installed font.
>
> The applications tested were LibreOffice Writer, Scribus DTP, Inkscape 
> (Win10: install demanded).
>
> Actually the results were failprove, in Scribus on Win10 even better 
> than on Linux. On the latter the E25x E27x sets were not show in the 
> symbols setup, but were added to the export field when typed.
>
> I'm afraid it is either a local fault, an application that not fully 
> supports symbols, or, as the Scribus test proved on Linux, still some 
> lack of experience with the magic of that paticular application.
>
> If you are interested in the images of the different views, just ask.
>
> Good luck finding out the cause.
> David
>
> Op 25-06-2025 om 18:35 schreef .rhavin Grobert via fontforge-users:
>> I have this Font (see attachment) and the glyphs E25D, E25F, E27D, 
>> E27F are shown in fontforge but when I install the font in Windows, 
>> they are not shown. All others are there.
>> Can anyone tell me why this happens?
>> Best regards, rhavin
>>
>>
>> _______________________________________________
>> fontforge-users mailing list
>> fon...@li...
>> https://lists.sourceforge.net/lists/listinfo/fontforge-users
>> http://fontforge.10959.n7.nabble.com/User-f8781.html
>
>
> _______________________________________________
> fontforge-users mailing list
> fon...@li...
> https://lists.sourceforge.net/lists/listinfo/fontforge-users
> http://fontforge.10959.n7.nabble.com/User-f8781.html

Re: [fontforge-users] Unicode Glyphs not shown in Windows 10

[Gé v. G. <gev...@gm...>]

On Fri, Jun 27, 2025 at 6:43 PM David J. Perry via fontforge-users <
fon...@li...> wrote:

> This goes back many years (15 to 20), so details are vague.  I do remember
> putting some glyphs in the the PUA, somewhere in the E000-E400 vicinity,
> and finding conflicts; the codepoints kept displaying as CJK characters if
> I recall correctly.  I can't remember if the problem was only in Word or in
> other programs as well.  I ended up moving the glyphs to locations further
> up in the PUA.
>
I have similar vague memories of characters in the PUA sometimes behaving
erratically.
My tentative conclusion back then was that Microsoft assumed some of the
character slots to contain its own glyphs, or some such thing, which caused
such compatibility issues.

So yes, if the OP can live with moving the problem characters to other
slots, that might be the easiest way to "solve" the problem.