Option needed to 'Save' as UFO

[vernnobile]

At moment the only file format FontForge can 'Save' as is .sfd, i would deeply love to have the option to save as a .ufo in exactly the same way that i can now save as a .sfd. This would allow fontforge to dovetail seamlessly and conveniently into a workflow with all the other UFO based font creation apps, e.g. robofont, glyphs, metrics machine, superpolator, prepolator, roundingUFO, UFOstretch, metapolator, etc etc

This could either be sone via a keystroke, or by a setting in fontforge preferences, to toggle the default file type between ufo and sfd

:-)

[davelab6]

What's wrong with Generating ufo?

[vernnobile]

The key here is using fontforge in a mixed workflow, where a font file is being 'shuttled' to and fro between different apps. Generating a UFO is simply too slow a process, compared to simply 'key+s'.
In a real world workflow situation, a designer may be moving from app to app continuously, each time saving the UFO with a 'key-s' so that changes are immeadiately reflected in all other apps using that UFO file (this is one of the major strengths of the UFO format). E.g. making tweaks between several UFOs for 'prepolating' or 'metapolating'. At the moment fontforge simply cannot join in that party :-( because a 'key+s' every minute, over several hours, is unproblematic, but generating a UFO at the same rate is just not practical. That's a major bad imho and could be a huge asset if it was fixed :)

[davelab6]

With scripting you can make a call to Generate() that is bound to a key, and with the new hotkeys file, its easy to unbind cmd+s from Save().

I'm not saying close the issue as invalid, I'm saying, this doesn't seem like a priority for me :)

[ghost]

On Mon, 19 Aug 2013, vernon adams wrote:

At moment the only file format FontForge can 'Save' as is .sfd, i would
deeply love to have the option to save as a .ufo in exactly the same way
that i can now save as a .sfd. This would allow fontforge to dovetail

This opens the same can of worms opened by the GIMP 2.8 save/export
debacle.

At the moment, when FontForge "saves," that always means SFD. Saving in
any other format is called "generating."

The justification for doing it the current way (I wasn't around when this
decision was made, so I'm guessing here) seems to be that SFD, and only
SFD, is lossless. SFD is unique in being more or less a direct dump of
FontForge's in-memory data structures, even to the point (see bug #515) of
preserving invalid information in those data structures. Any other format
loses some information that the user might want to retain, and any format
defined by an entity other than FontForge runs the risk of becoming unable
to store all of FontForge's information in the future, even if we could
make it work losslessly today.

So it's a bad thing if the user is encouraged to unknowingly use a format
from which they will later be unable to recover information they wanted to
save. Using a separate "generate" command makes it clearer that this is a
one-way operation. If you are working on a font in FontForge and later
want to pick up where you left off, you'll probably want to use the "save"
command and SFD format; if you are moving between FontForge and other
software, you'll probably want to use "generate" and some other format,
and you won't be able to pick it up losslessly in FontForge.

Separating out "generate" has a minor benefit of making the UI coding
simpler: for "save" we can use the standard "Save" dialogue (good because
it'll be familiar to users) while for "generate" we can prompt the user
for the (in some formats quite extensive) additional information needed by
format-specific options.

I think that the way these things currently work in FontForge is not badly
broken, but a strong case could be made for making "save" work with all
formats and eliminating the separation between "save" and "generate."
I'd support a proposal to do that if and only if it were for all formats
(not just UFO) and included some reasonably unintrusive way of warning the
user about lossy conversions. For instance, the "save" dialogue could
have a drop-down box for format, with a label that changes when a lossy
format is selected to say something like "this is a lossy format; not all
information in the font will be saved." Not a dialogue requiring a click,
please!

I don't think it is reasonable for "save" to do just SFD or UFO, with all
other formats separated into "generate." There's arguably some reason for
SFD to be different from other formats but there's no reason for UFO to be
different.

seamlessly and conveniently into a workflow with all the other UFO based
font creation apps, e.g. robofont, glyphs, metrics machine, superpolator,
prepolator, roundingUFO, UFOstretch, metapolator, etc etc

Users, especially me, hate being told what workflow to use. Even if you
don't actively break my workflow, if you provide special privileges for
users of some other workflow and promote that as preferred then I'm going
to end up resentful about it. I have a mostly Postscript-based workflow
and I never touch UFO at all. Some other people work the way I do and
many use other formats again. UFO workflows do not have unique needs
meriting special status.

In any case, before we do anything that even implies that a UFO-based
workflow could be acceptable let alone encouraged, we had better be very
sure we can really load and save UFO files properly. I haven't been
paying close attention because I never use UFO myself, but I think I've
seen a lot of traffic on this list in the last few months about bugs in
FontForge's implementation of UFO, and even some claims from developers
that FontForge's alleged inability to exchange UFO files with other
software is the other software's fault and not FontForge's. That cannot
stand if people really do want to use FontForge as a seamless part of some
external UFO ecosystem. It must really work even if it means patching
around someone else's breakage, and even if it's unfair.

On implementation: having "what does save mean?" be a setting in a
separate preferences command instead of in the save dialogue itself is a
great way to create unnecessary surprises for users. It'd be yet another
piece of hidden state to prevent me from knowing what the commands I issue
will actually do. What's wrong with the approach all other software worth
considering does: a save dialogue that saves all formats and allows the
user to choose the format when saving? Alternatively, what's wrong with
leaving well enough alone?

This could either be sone via a keystroke, or by a setting in fontforge
preferences, to toggle the default file type between ufo and sfd

I've said this before, but in this project changing the defaults seems to

be the first choice way of solving problems. It should be the last choice.

Matthew Skala
mskala@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

[davelab6]

On 19 August 2013 12:50, Matthew Skala notifications@github.com wrote:

I don't think it is reasonable for "save" to do just SFD or UFO, with all
other formats separated into "generate." There's arguably some reason for
SFD to be different from other formats but there's no reason for UFO to be
different.

The reason is that UFO is a 'source form' format, like SFD; all the others
are 'usage form' and, with the exception of SVG, in binary.

However, I like the reasoning that the GIMP team have for the difference
between Save and Export, and I think the same applies here for Save and
Generate.

[vernnobile]

"With scripting you can make a call to xxxx"
That's an argument you could make for any new feature requests ;P
sulk.

[davelab6]

If you look at what I've asked @monkeyiq to work on, its stuff that users
in workshops hit that can't be done with scripting ;p

[vernnobile]

"Users, especially me, hate being told what workflow to use."
Same here, that's why i would love to have the option of using FontForge much more integrally in my workflow.

"I haven't been
paying close attention because I never use UFO myself, but I think I've
seen a lot of traffic on this list in the last few months about bugs in
FontForge's implementation of UFO"
Those issues have been addressed and fixed. Fontforge is now able to generate and open UFO's seamlessly now.

[ghost]

For me Postscript and BFD are "source" formats and OpenType is a "usage" format. BFD is text and Postscript has a text version, by the way. These are distinctions that I don't think should require separate commands. What I do think might arguably be a good basis for a separate command is the native/non-native distinction, or the (nearly identical) lossless/lossy distinction. But in the case of GIMP I don't even find that argument convincing, as you can see in my profile here on Github.

[davelab6]

I think native/non native is the gimp argument? :-)

[vernnobile]

UFO is a source file format. It's used by the majority of font creation applications as default source format. My request was not based on the idea that FontForge should adopt UFO as it's single default, but that Fontforge could output UFO's from a 'key-s' (or similar) rather than the slow, full, 'generate font' process. As Dave says, automating the generate UFO process can be easilly implemented via scripting, which is ok, but not 100% ideal. Imo fontforge would be a better type design asset if it could more fully integrate with modern type design systems.

ps - i'll leave this issue open, but have down-labelled it as 'someday-maybe', just in case some luminary coder picks it up sometime :)

[ultrasquid]

It seems to me, with UFO being promoted as an interchange format for font
editing, it should be at least offered as an option in the Save As… dialog.
Sift out any other "source" formats and make those Save As options too. But
limit those to the formats that can carry a complete font database.

Let's stop and take a look at what we currently have:

Save As… lets you save into sfd and sfdir formats. These are native
FontForge files and the only option is a toggle between those two. This is
OK for what it is
.
Generate Font has 26 format options including several flavors of
PostScript, Truetype, and CFF among others, along with Unified Font Object,
plus several additional options that are not fully applicable to all the
formats. In my opinion this could be broken up and clarified in some way.
It's a mess.
What among the Generate options are relevant or necessary for UFO format?
If the answer is few or none, that would make it a good candidate to move
to the Save As dialog,

If we look at it as being neither native FF format nor a usable compiled
font format, maybe it would be worth it to make a separate Export menu item
and dialog for UFO and other uncompiled formats should FF gain the ability
to write to them

On Mon, Aug 19, 2013 at 10:17 AM, Matthew Skala notifications@github.comwrote:

For me Postscript and BFD are "source" formats and OpenType is a "usage"
format. BFD is text and Postscript has a text version, by the way. These
are distinctions that I don't think should require separate commands. What
I do think might arguably be a good basis for a separate command is the
native/non-native distinction, or the (nearly identical) lossless/lossy
distinction. But in the case of GIMP I don't even find that argument
convincing, as you can see in my profile here on Github.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/669#issuecomment-22888305
.

Jason Pagura
zimbach at gmail dot com

[ghost]

Even if I mentioned GIMP, I'd rather talk about FontForge. FontForge developers definitely, and FontForge users probably, care a lot about the possibility of work being accidentally lost. Look at all the discussions we've had of versioned backups (#101), timed backups (#410), crash recovery snapshots, preserving subtable names through a save and load, preserving the very order of records in the SFD file through a save and load (#518 - which I think is baloney, but a user cared about it) and so on.

If a file is ever saved in a lossy format and subsequently loaded, then some information may be lost in a way the user didn't intend. It appears to be a priority (not my priority, but the project's priority) that such a thing shouldn't happen. I think that is the main reason, and the only reason still relevant today, that "Save" only saves lossless formats and the "Generate" command exists for other formats. But having the two separate commands creates annoyance for anyone who really does want to use a lossy format as their main format and is willing to accept the consequences of using a lossy format. It's not just which menu option you use: there are also issues like how if you save a non-SFD format and then try to quit, the program will tell you you have unsaved changes.

If we move even one lossy format to "Save," then we lose the only real advantage of having separate "Save" and "Generate" commands. If we don't move ALL formats to "Save," then we don't gain the advantage of removing the save/generate distinction. So it makes sense to me to not move any lossy formats to "Save," or to move ALL formats to "Save," but not anything in between. Moving some lossy formats and not all of them gives us the worst of both options.

It doesn't make sense to me to try to draw distinctions between lossy formats that belong in "Save," and lossy formats that belong in "Generate," based on whether they are "source" or "compiled." I don't know what that means, neither do you, and our users certainly don't know it intuitively. We don't even have a reason to need such a distinction, so why try to define it and then have to explain and defend it? What would we lose by having all formats in "save" compared to having all "source" formats?

A side issue: @vernnobile describes saving into UFO and having the changes appear immediately in other applications as an advantage of UFO. I don't understand what that has to do with UFO at all. That's just file watching, which works if and only if the other software knows how to do it. It's equally possible in any format; and it would work a lot better in any format if we could address issues #486 and #637 to make it work in the opposite direction too. It sounds like saving to UFO is also slower than it should be, but that too has nothing to do with whether it happens through "save" or "generate."

[vernnobile]

"@vernnobile describes saving into UFO and having the changes appear immediately in other applications as an advantage of UFO. I don't understand what that has to do with UFO at all"

UFO is a font source file format that is application independent, hence the 'unified' aspect of it. This becomes an advantage when a font file is being 'watched' by separate applications working on the same source file, so that each application is able to read / edit / save the font without causing unnecessary changes to the font that would prevent or hinder any of the other applications working on that file. My point about FontForge's inability to 'save' as a UFO is that it is hindering itself in being part of that shared font design system. I just think that it a real shame, and a missed opportunity to add even more asset to fontforge.

[davelab6]

On 19 August 2013 16:10, vernon adams notifications@github.com wrote:

My point about FontForge's inability to 'save' as a UFO is that it is
hindering itself in being part of that shared font design system. I just
think that it a real shame, and a missed opportunity to add even more asset
to fontforge.

You can create the functionality you want with
http://fontforge.org/scripting.html

Using the Mac app, hit Cmd-. or File, Execute Script, then just
Generate('font.ufo') and the file appears in your Home directory. You can
save a file called generate.ff and set it up in File, Preferences, Script
Menu, then either run it directly from the menu (File->Scripts->) or by a hot key: The first script you added will be invoked by
Cnt-Alt-1, then second by Cnt-Alt-2, and the tenth by Cnt-Alt-0.

If you compile FF with Homebrew and get Python scripting, you can unbind
Cmd-S by editing the hotkeys file and then making a simple script that
generates the font based on the PS Name:

https://gist.github.com/davelab6/6362877

(update: @vernnobile confirmed this works)

[khaledhosny]

For anyone who believes in the Unified part of UFO, I’ve got a bridge to sell you. As for source format thing, Type1 fonts can store just a bit more font data and metadata than UFO.

[ultrasquid]

On a related, but probably separate note, UFO is NOT one of the filter options in the Open Font dialog. It's also not among the options in the Import dialog either. If we're going to put effort into making FF Save as UFO as an nearly native format, shouldn't it be more obviously workable at the other end of the process?

[vernnobile]

One, it seems like there is not any will to make UFO a second native
fontforge file type. Two, fontforge opens UFO's fine (now the old issues
have been fixed).
On 25 Aug 2013 08:12, "Jason P." notifications@github.com wrote:

On a related, but probably separate note, UFO is NOT one of the filter
options in the Open Font dialog. It's also not among the options in the
Import dialog either. If we're going to put effort into making FF Save as
UFO as an nearly native format, shouldn't it be more obviously workable at
the other end of the process?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/669#issuecomment-23229337
.

[ultrasquid]

OK, so that Open dialog filter omission is a separate issue

[khaledhosny]

One, it seems like there is not any will to make UFO a second native fontforge file type.

No, UFO _can’t_ be a native font format, period. I don’t know what kind of fonts you make, but UFO can’t even represent the simplest of fonts I work on. Ignoring all the limitations of UFO and misleading users to think it can save any font FontForge make is a dishonest thing to do.

[vernnobile]

Please read the original issue submission. This is NOT about forcing
fontforge to use UFO as a 'native' (whatever the pedantics of that word
are) file format. My only submission was that fontforge could be creating
UFO files via the 'save' route and not just the 'generate font' route. The
reason would be to enable fontforge to more seamlessly fit into a font
creation system using those other apps that simply save as UFOs (robofont,
metrics machine, etc etc). You probably have to be using that type of
system to understand what I mean by this issue. I'll make a screen cast to
illustrate.
On 27 Aug 2013 01:09, "Khaled Hosny" notifications@github.com wrote:

One, it seems like there is not any will to make UFO a second native
fontforge file type.

No, UFO can’t be a native font format, period. I don’t know what kind
of fonts you make, but UFO can’t even represent the simplest of fonts I
work on. Ignoring all the limitations of UFO and misleading users to think
it can save any font FontForge make is a dishonest thing to do.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/669#issuecomment-23319432
.

[ghost]

I still don't understand how it makes sense for UFO to be handled differently from the dozens of other non-SFD formats FontForge supports.

[ultrasquid]

When I go to Generate Fonts, I expect whatever outputs from that to be a
file that I can drop in the appropriate directory in an operating system
and start typing letters with the shapes that I drew. To my knowledge, no
OS is capable of using the UFO format in this way. Therefore, I don't feel
that by saving a UFO file that I've "generated" a "font". Therefore, either
UFO should be an option under File>Save As… or it should be added into a
new File>Export as… dialog, for UFO and other formats that are used by
other font editing programs that are not fully compiled fonts usable by
operating systems. As I said earlier, the Generate Font dialog is a mess,
and this would be one step toward cleaning it up.

On Tue, Aug 27, 2013 at 8:52 AM, Matthew Skala notifications@github.comwrote:

I still don't understand how it makes sense for UFO to be handled
differently from the dozens of other non-SFD formats FontForge supports.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/669#issuecomment-23347538
.

Jason Pagura
zimbach at gmail dot com

[vernnobile]

Yep. Jason gets it :)

A UFO file is not a true 'end user' font file, instead it is a file format designed to be used between software application that are designing fonts. The UFO format has been developed to (among other things) allow these UFO files to be edited by multiple applications working in the same workflow / design system. There's a long list now of applications that can 'plug-into' these sorts of UFO-based workflows, sadly fontforge is not really 100% one of them, but, ONLY because the process of saving a font in fontforge to UFO is via the 'generate font' route, and that is a route that takes too many menu clicks for it to be sensible. If Fontforge could simply do a 'ctrl+key' to save as a UFO, it would fully fit into these font design systems.

-v

On 27 Aug 2013, at 09:34, "Jason P." notifications@github.com wrote:

When I go to Generate Fonts, I expect whatever outputs from that to be a
file that I can drop in the appropriate directory in an operating system
and start typing letters with the shapes that I drew. To my knowledge, no
OS is capable of using the UFO format in this way. Therefore, I don't feel
that by saving a UFO file that I've "generated" a "font". Therefore, either
UFO should be an option under File>Save As… or it should be added into a
new File>Export as… dialog, for UFO and other formats that are used by
other font editing programs that are not fully compiled fonts usable by
operating systems. As I said earlier, the Generate Font dialog is a mess,
and this would be one step toward cleaning it up.

[khaledhosny]

I think File → Export can be a good place for UFO, except that we already have File → Import that imports individual glyphs rather than complete font files/bitmap only fonts, so we would end up with Import/Export having non-orthogonal functions.

[ghost]

While we're at this, why is "Generate Mac family" a separate menu option?

[khaledhosny]

And generally, I agree with Dave here, just use the Python snippet he provided, give it the shortcut you want and call it a day. We have scripting support for that kind of stuff.

[davelab6]

On 27 August 2013 19:24, vernon adams notifications@github.com wrote:

If Fontforge could simply do a 'ctrl+key' to save as a UFO, it would fully
fit into these font design systems.

I explained how to set this up already? :)

[davelab6]

On 27 August 2013 20:04, Khaled Hosny notifications@github.com wrote:

I think File → Export can be a good place for UFO

I don't see any value in having a 3rd creation dialog. I think Save for
native SFD and SomethingElse for non-native file formats makes the most
sense; and for a 'one keypress to export' workflow scripting is appropriate
for that.

[davelab6]

I fixed it, it had some deps missing
Homebrew/legacy-homebrew#22201
https://gist.github.com/davelab6/6380365

[davelab6]

Hmm it just crashes

$ brew install fontforge --with-x --HEAD --debug;
...
==> Cloning https://github.com/fontforge/fontforge.git
Updating /Library/Caches/Homebrew/fontforge--git
==> ./autogen.sh
==> ./configure --prefix=/usr/local/Cellar/fontforge/HEAD --enable-double --without-freetype-bytecode --without-cairo --without-pango --with-static-imagelibs --enable-pyextension
Warning: inreplace: replacement of 'ln -s /usr/local/bin/fontforge' with 'ln -s $(bindir)/fontforge' failed
Warning: inreplace: replacement of 'python setup.py install --prefix=$(prefix) --root=$(DESTDIR)' with '/usr/bin/python setup.py install --prefix=$(prefix)' failed
Warning: inreplace: replacement of '/Developer/Headers/FlatCarbon/Files.h' with 'CarbonCore/Files.h' failed
Warning: inreplace: replacement of '/Developer/Headers/FlatCarbon/Files.h' with 'CarbonCore/Files.h' failed
Warning: inreplace: replacement of '/Developer/Headers/FlatCarbon/Files.h' with 'CarbonCore/Files.h' failed
Warning: inreplace: replacement of '/Developer/Headers/FlatCarbon/CarbonEvents.h' with 'HIToolbox/CarbonEvents.h' failed
==> make
==> make install
Fixing /usr/local/Cellar/fontforge/HEAD/bin/sfddiff permissions from 100755 to 555
Fixing /usr/local/Cellar/fontforge/HEAD/bin/fontlint permissions from 100755 to 555
Fixing /usr/local/Cellar/fontforge/HEAD/bin/fontimage permissions from 100755 to 555
Fixing /usr/local/Cellar/fontforge/HEAD/bin/fontforge permissions from 100755 to 555
Fixing /usr/local/Cellar/fontforge/HEAD/lib/python2.7/site-packages/psMat.so permissions from 100755 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/python2.7/site-packages/fontforge.so permissions from 100755 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/pkgconfig/libfontforgeexe.pc permissions from 100644 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/pkgconfig/libfontforge.pc permissions from 100644 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libgutils.a permissions from 100644 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libgutils-2.0.0_beta1.dylib permissions from 100755 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libgunicode.a permissions from 100644 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libgunicode-2.0.0_beta1.dylib permissions from 100755 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libgioftp.a permissions from 100644 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libgioftp-2.0.0_beta1.dylib permissions from 100755 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libgdraw.a permissions from 100644 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libgdraw-2.0.0_beta1.dylib permissions from 100755 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libfontforgeexe.a permissions from 100644 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libfontforgeexe-2.0.0_beta1.dylib permissions from 100755 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libfontforge.a permissions from 100644 to 444
Fixing /usr/local/Cellar/fontforge/HEAD/lib/libfontforge-2.0.0_beta1.dylib permissions from 100755 to 444
==> Caveats
fontforge is an X11 application.

To install the Mac OS X wrapper application run:
  brew linkapps
or:
  ln -s /usr/local/opt/fontforge/FontForge.app /Applications
For non-homebrew python (2.x), you need to amend your PYTHONPATH like so:
  export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH
==> Summary
  /usr/local/Cellar/fontforge/HEAD: 1412 files, 42M, built in 5.3 minutes


$ /usr/local/bin/fontforge 
Copyright (c) 2000-2012 by George Williams. See AUTHORS for contributors.
 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
 with many parts BSD <http://fontforge.org/license.html>. Please read LICENSE.
 Executable based on sources from 18:28 CEST 29-Aug-2013-ML-D.
 Library based on sources from 18:28 CEST 29-Aug-2013.
 Based on source from git with hash:
PythonUI_Init()
CreateAllPyModules()
fontforge(83479,0x7fff74609180) malloc: *** error for object 0x7fc1acd01ce0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6


$ lldb /usr/local/bin/fontforge 
Current executable set to '/usr/local/bin/fontforge' (x86_64).
(lldb) r
Process 83368 launched: '/usr/local/bin/fontforge' (x86_64)
Copyright (c) 2000-2012 by George Williams. See AUTHORS for contributors.
 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
 with many parts BSD <http://fontforge.org/license.html>. Please read LICENSE.
 Executable based on sources from 18:28 CEST 29-Aug-2013-ML-D.
 Library based on sources from 18:28 CEST 29-Aug-2013.
 Based on source from git with hash:
PythonUI_Init()
CreateAllPyModules()
fontforge(83368,0x7fff74609180) malloc: *** error for object 0x103c11d30: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Process 83368 stopped
* thread #1: tid = 0x1c03, 0x00007fff8732b212 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    frame #0: 0x00007fff8732b212 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill + 10:
-> 0x7fff8732b212:  jae    0x7fff8732b219            ; __pthread_kill + 17
   0x7fff8732b214:  jmpq   0x7fff8732c4d4            ; cerror_nocancel
   0x7fff8732b219:  ret    
   0x7fff8732b21a:  nop    
(lldb) bt
* thread #1: tid = 0x1c03, 0x00007fff8732b212 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    frame #0: 0x00007fff8732b212 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff8f4feb54 libsystem_c.dylib`pthread_kill + 90
    frame #2: 0x00007fff8f542dce libsystem_c.dylib`abort + 143
    frame #3: 0x00007fff8f5169b9 libsystem_c.dylib`free + 392
    frame #4: 0x0000000100c6607b libfontconfig.1.dylib`FcValueListDestroy + 55
    frame #5: 0x0000000100c66406 libfontconfig.1.dylib`FcPatternDestroy + 110
    frame #6: 0x0000000100bf82b0 libpangoft2-1.0.0.dylib`pango_fc_font_map_get_resolution + 217
    frame #7: 0x0000000100bf6ed3 libpangoft2-1.0.0.dylib`pango_fc_font_map_load_fontset + 355
    frame #8: 0x0000000100c1313f libpango-1.0.0.dylib`itemize_state_process_run + 499
    frame #9: 0x0000000100c12c06 libpango-1.0.0.dylib`pango_itemize_with_base_dir + 147
    frame #10: 0x0000000100c18147 libpango-1.0.0.dylib`pango_layout_check_lines + 620
    frame #11: 0x0000000100c1b7e0 libpango-1.0.0.dylib`pango_layout_get_extents_internal + 47
    frame #12: 0x0000000100c1bb31 libpango-1.0.0.dylib`pango_layout_get_pixel_extents + 71
    frame #13: 0x0000000100650b12 libgdraw-2.0.0_beta1.dylib`_GXPDraw_DoText8 + 112
    frame #14: 0x0000000100650e23 libgdraw-2.0.0_beta1.dylib`_GXPDraw_DoText + 99
    frame #15: 0x000000010060e295 libgdraw-2.0.0_beta1.dylib`GDrawGetTextWidth + 44
    frame #16: 0x0000000100145399 libfontforgeexe-2.0.0_beta1.dylib`fontforge_main + 3843
    frame #17: 0x00007fff839227e1 libdyld.dylib`start + 1
(lldb) q

[monkeyiq]

OK after installing using homebrew, then applying a patch generated as the diff of @davelab6's homebrew fork and the mxcl base on github I got fontforge installed and was greeted with the same backtrace as @davelab6 has shown in the above comment :)

I had suspected when I saw this backtrace that it related to pango's font render path and how pango got built. To check this assumption I copied the pango from the macports daily build and the dependant libraries (a few wanted later versions, many are just the paths in the macports being different to those in homebrew). With a link /opt/local to /usr/local to help the paths issue, I was able to run the homebrew compiled fontforge against the alternate pango and have the fontview appear etc with no crash.

One difference between the two pango builds is that the macports one which is used to make the daily app.zip file doesn't use the CoreText libraries at all...

osx:lib ben$ type ldd
ldd is aliased to `otool -L'
osx:lib ben$ ldd libpangocairo-1.0.0.dylib |grep Core
osx:lib ben$ cd ./orig
osx:orig ben$ ldd libpangocairo-1.0.0.dylib |grep Core
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.0.0)
        /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText (compatibility version 1.0.0, current version 275.14.0)
osx:orig ben$ 

Perhaps there is a way for fontforge to prep cairo/pango to force the X11 backend even in the presence of the CoreText one. My next stop will probably be looking at how homebrew compiles its pango stuff.

[monkeyiq]

For reference, this is what brew installed in the process of installing fontforge, and what the macports machine is using.

Brew pango

osx:2.7 ben$ brew info pango
pango: stable 1.34.1
http://www.pango.org/
/usr/local/Cellar/pango/1.34.1 (119 files, 4.1M) *
  Built from source
From: https://github.com//homebrew/commits/master/Library/Formula/pango.rb
==> Dependencies
Build: pkg-config, xz
Required: glib, cairo, harfbuzz, fontconfig
==> Options
--without-x
        Build without X11 support

macports pango

RSD:~ ben$ port info pango
Warning: port definitions are more than two weeks old, consider using selfupdate
pango @1.34.1, Revision 1 (x11)
Variants:             builtin_modules, quartz, (+)universal, [+]x11

Description:          The goal of the Pango project is to provide an open-source framework for the layout and rendering of
                      internationalized text.
Homepage:             http://www.pango.org/

Extract Dependencies: xz
Build Dependencies:   pkgconfig
Library Dependencies: glib2, cairo, gobject-introspection, harfbuzz, Xft2
Conflicts with:       pango-devel
Platforms:            darwin
License:              LGPL-2
Maintainers:          ryandesign@macports.org, openmaintainer@macports.org

[monkeyiq]

oh, and this is the install command I used to trigger the pango (just for reference while it is still in up arrow history)

brew install fontforge --with-x --HEAD ---debug

[monkeyiq]

If one removes the generation of --without-cairo --without-pango from the fontforge.rb build then it seems all goes well. ie, if the configure is allowed to find and use cairo + pango it runs is ok. I just also tried a build without cairo but with pango and no dice there.

If there are no issues with making cairo and pango hard deps then it would make things a bunch simpler with builds.

[ultrasquid]

The only reason for Pango and Cairo not to be hard dependencies seems to be
historical; FF originally didn't use them (I'm not sure what was there
before, but I remember there was quite a row in the Dev ML when Pango and
Cairo were brought in to supplant/replace it), so the option is there to
exclude them seemingly for sentimental reasons. But now that the current
form of FF breaks without them, it makes no sense to allow those libraries
to be optional.

On Mon, Sep 9, 2013 at 10:30 PM, monkeyiq notifications@github.com wrote:

If one removes the generation of --without-cairo --without-pango from the
fontforge.rb build then it seems all goes well. ie, if the configure is
allowed to find and use cairo + pango it runs is ok. I just also tried a
build without cairo but with pango and no dice there.

If there are no issues with making cairo and pango hard deps then it would
make things a bunch simpler with builds.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/669#issuecomment-24134556
.

Jason Pagura
zimbach at gmail dot com

[monkeyiq]

I was a bit suspicious I had clobbered something while testing. A fresh machine with @davelab6 homebrew changes and removing the force off for cairo and pango runs ok.

Though I got a python error and had to do the following to make it happy. Likely caused by me not knowing homebrew and not reading the link that was given after brew install python completed.

osx:include root# pwd
/usr/include
osx:include root# ln -s /usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/include/python2.7 .

[davelab6]

@monkeyiq That's great research! I have updated my fontforge.rb and now FontForge's GUI runs - the pull request is still open, not sure what the delay is to be honest.... https://github.com/davelab6/homebrew/blob/master/Library/Formula/fontforge.rb

Re: making a symlink, there is a standard python caveat for brew:

For non-homebrew python (2.x), you need to amend your PYTHONPATH like so:
  export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH

You should be able to rm that symlink and use the above in your .profile :)

However, when I run FF, I get the open dialog, I click "new" and then click the "A" glyph and get this crash:

Script started on Tue Sep 10 16:13:55 2013
(lldb) Executing commands in 'fontforge-debug.sh'.
(lldb)  version
LLDB-179.5
(lldb)  settings set frame-format "frame #${frame.index}: ${frame.pc}{ ${module.file.basename}`${function.name-with-args}{${function.pc-offset}}}{ at ${line.file.basename}:${line.number}}\n"
(lldb)  target create /usr/local/bin/fontforge
Current executable set to '/usr/local/bin/fontforge' (x86_64).
(lldb)  target select 0
Current targets:
* target #0: /usr/local/bin/fontforge ( arch=x86_64-apple-macosx, platform=localhost )
(lldb)  run
Process 59958 launched: '/usr/local/bin/fontforge' (x86_64)
Command #5 'run' continued the target.
Copyright (c) 2000-2012 by George Williams. See AUTHORS for contributors.

 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

 with many parts BSD <http://fontforge.org/license.html>. Please read LICENSE.

 Executable based on sources from 15:17 CEST 10-Sep-2013-ML-D.

 Library based on sources from 15:17 CEST 10-Sep-2013.

 Based on source from git with hash:

PythonUI_Init()

CreateAllPyModules()

Warning: No modifiers in short cut: §

fontforge(59958,0x7fff7cb85180) malloc: *** error for object 0x102653ea0: pointer being freed was not allocated

*** set a breakpoint in malloc_error_break to debug


�[KProcess 59958 stopped
* thread #1: tid = 0x1c03, 0x00007fff930e9212 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    "frame #0: 0x00007fff930e9212 libsystem_kernel.dylib`__pthread_kill + 10
"libsystem_kernel.dylib`__pthread_kill + 10:
-> 0x7fff930e9212:  jae    0x7fff930e9219            ; __pthread_kill + 17
   0x7fff930e9214:  jmpq   0x7fff930ea4d4            ; cerror_nocancel
   0x7fff930e9219:  ret    
   0x7fff930e921a:  nop    
(lldb) bt

* thread #1: tid = 0x1c03, 0x00007fff930e9212 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    "frame #0: 0x00007fff930e9212 libsystem_kernel.dylib`__pthread_kill + 10
"    "frame #1: 0x00007fff8e4c5b54 libsystem_c.dylib`pthread_kill + 90
"    "frame #2: 0x00007fff8e509dce libsystem_c.dylib`abort + 143
"    "frame #3: 0x00007fff8e4dd9b9 libsystem_c.dylib`free + 392
"    "frame #4: 0x0000000100d96dd7 libfontconfig.1.dylib`FcValueListDestroy + 55
"    "frame #5: 0x0000000100d97162 libfontconfig.1.dylib`FcPatternDestroy + 110
"    "frame #6: 0x0000000100d272b0 libpangoft2-1.0.0.dylib`pango_fc_font_map_get_resolution + 217
"    "frame #7: 0x0000000100d25ed3 libpangoft2-1.0.0.dylib`pango_fc_font_map_load_fontset + 355
"    "frame #8: 0x0000000100d25d30 libpangoft2-1.0.0.dylib`pango_fc_font_map_load_font + 59
"    "frame #9: 0x000000010065c2f1 libgdraw-2.0.0_beta1.dylib`_GXPDraw_FontMetrics + 88
"    "frame #10: 0x000000010003a5eb libfontforgeexe-2.0.0_beta1.dylib`CharIcon + 675
"    "frame #11: 0x000000010003f98e libfontforgeexe-2.0.0_beta1.dylib`CharViewCreateExtended + 242
"    "frame #12: 0x00000001000ba19d libfontforgeexe-2.0.0_beta1.dylib`v_e_h + 5517
"    "frame #13: 0x0000000100614998 libgdraw-2.0.0_beta1.dylib`_GWidget_Container_eh + 1541
"    "frame #14: 0x0000000100657f2b libgdraw-2.0.0_beta1.dylib`dispatchEvent + 5753
"    "frame #15: 0x00000001006556d0 libgdraw-2.0.0_beta1.dylib`GXDrawEventLoop + 65
"    "frame #16: 0x00000001001464fc libfontforgeexe-2.0.0_beta1.dylib`fontforge_main + 6574
"    "frame #17: 0x00007fff904c67e1 libdyld.dylib`start + 1
"(lldb) q


Script done on Tue Sep 10 16:14:04 2013

[davelab6]

Hmm I thought it might be similar, and resolved by including fontconfig in the build environment, but that didnt help (https://gist.github.com/davelab6/6510156)

[monkeyiq]

It seems opening the metrics window already worked. Hopefully that gets the brew'ed fontforge working for folks ;)

[davelab6]

Seems the ' Based on source from git with hash:' line is broken...

Script started on Sat Sep 14 02:51:29 2013
(lldb) Executing commands in 'fontforge-debug.sh'.
(lldb)  version
LLDB-179.5
(lldb)  settings set frame-format "frame #${frame.index}: ${frame.pc}{ ${module.file.basename}`${function.name-with-args}{${function.pc-offset}}}{ at ${line.file.basename}:${line.number}}\n"
(lldb)  target create /usr/local/bin/fontforge
Current executable set to '/usr/local/bin/fontforge' (x86_64).
(lldb)  target select 0
Current targets:
* target #0: /usr/local/bin/fontforge ( arch=x86_64-apple-macosx, platform=localhost )
(lldb)  run
Process 82930 launched: '/usr/local/bin/fontforge' (x86_64)
Command #5 'run' continued the target.
Copyright (c) 2000-2012 by George Williams. See AUTHORS for contributors.

 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

 with many parts BSD <http://fontforge.org/license.html>. Please read LICENSE.

 Executable based on sources from 02:49 CEST 14-Sep-2013-ML-D.

 Library based on sources from 02:49 CEST 14-Sep-2013.

 Based on source from git with hash:

PythonUI_Init()

CreateAllPyModules()

Warning: No modifiers in short cut: §

fontforge(82930,0x7fff7cb85180) malloc: *** error for object 0x108d35690: pointer being freed was not allocated

*** set a breakpoint in malloc_error_break to debug


�[KProcess 82930 stopped
* thread #1: tid = 0x1c03, 0x00007fff930e9212 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    "frame #0: 0x00007fff930e9212 libsystem_kernel.dylib`__pthread_kill + 10
"libsystem_kernel.dylib`__pthread_kill + 10:
-> 0x7fff930e9212:  jae    0x7fff930e9219            ; __pthread_kill + 17
   0x7fff930e9214:  jmpq   0x7fff930ea4d4            ; cerror_nocancel
   0x7fff930e9219:  ret    
   0x7fff930e921a:  nop    
(lldb) bt

* thread #1: tid = 0x1c03, 0x00007fff930e9212 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    "frame #0: 0x00007fff930e9212 libsystem_kernel.dylib`__pthread_kill + 10
"    "frame #1: 0x00007fff8e4c5b54 libsystem_c.dylib`pthread_kill + 90
"    "frame #2: 0x00007fff8e509dce libsystem_c.dylib`abort + 143
"    "frame #3: 0x00007fff8e4dd9b9 libsystem_c.dylib`free + 392
"    "frame #4: 0x0000000100d96dd7 libfontconfig.1.dylib`FcValueListDestroy + 55
"    "frame #5: 0x0000000100d97162 libfontconfig.1.dylib`FcPatternDestroy + 110
"    "frame #6: 0x0000000100d272b0 libpangoft2-1.0.0.dylib`pango_fc_font_map_get_resolution + 217
"    "frame #7: 0x0000000100d25ed3 libpangoft2-1.0.0.dylib`pango_fc_font_map_load_fontset + 355
"    "frame #8: 0x0000000100d25d30 libpangoft2-1.0.0.dylib`pango_fc_font_map_load_font + 59
"    "frame #9: 0x000000010065c2f1 libgdraw-2.0.0_beta1.dylib`_GXPDraw_FontMetrics + 88
"    "frame #10: 0x000000010003a61b libfontforgeexe-2.0.0_beta1.dylib`CharIcon + 675
"    "frame #11: 0x000000010003f9be libfontforgeexe-2.0.0_beta1.dylib`CharViewCreateExtended + 242
"    "frame #12: 0x00000001000ba1d5 libfontforgeexe-2.0.0_beta1.dylib`v_e_h + 5517
"    "frame #13: 0x0000000100614980 libgdraw-2.0.0_beta1.dylib`_GWidget_Container_eh + 1541
"    "frame #14: 0x0000000100657f2b libgdraw-2.0.0_beta1.dylib`dispatchEvent + 5753
"    "frame #15: 0x00000001006556d0 libgdraw-2.0.0_beta1.dylib`GXDrawEventLoop + 65
"    "frame #16: 0x000000010014653c libfontforgeexe-2.0.0_beta1.dylib`fontforge_main + 6574
"    "frame #17: 0x00007fff904c67e1 libdyld.dylib`start + 1
"(lldb) q


Script done on Sat Sep 14 02:51:41 2013

[monkeyiq]

Just in case this winds up making a difference I'm on Xcode 4.4 which is indicated as outdated. Though that's also the exact version I use for the macports build.

[monkeyiq]

It seems brew clones the git repo to /Library/Caches/Homebrew/fontforge--git but runs the compile in a copy at /private/tmp/fontforge-55m2/ which itself doesn't include the .git directory. So that's why the git hash is not being detected.

[davelab6]

OK thats a pity

[monkeyiq]

Hmm, runs ok here. If you don't see the fontview window at all, did you remove the cairo/pango options from fontforge.rb?

The base repo for fontforge that brew seems to use is at:
brew /Library/Caches/Homebrew/fontforge--git$ git log --pretty=format:'%H' -n 1
df90ff9

Brew versions of some libs I have installed:
pango: stable 1.34.1
cairo: stable 1.12.16
fontconfig: stable 2.10.95

gcc -v gives
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

[davelab6]

If it runs OK for you, lets move on :)

I don't see the fontview window at all. https://gist.github.com/davelab6/6380365/raw/360afb889270c37b5864ff86fc6483cdf3a24495/fontforge.rb is the hb formula I'm using.

/Library/Caches/Homebrew/fontforge--git$ git log --pretty=format:'%H' -n 1
35fa904b250f7daa40a8d894ecdf099a2338211e
$ pango-view --version
pango-view (pango) 1.34.1
$ cairo-trace --version
cairo-trace, version 1.12.16.
$ gcc -v
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

Its 10.8.4.

[davelab6]

Now it works for me. :)

[ultrasquid]

Hold on, what issue did we just fix? This started on adding UFO as a "Save
As…" format option in addition to or instead of the Generate Font option.
From the limited amount I could understand, I think we fixed something
else entirely.

On Tue, Sep 17, 2013 at 1:09 PM, Dave Crossland notifications@github.comwrote:

Now it works for me. :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/669#issuecomment-24618161
.

Jason Pagura
zimbach at gmail dot com

[marnen]

@ultrasquid Agreed. If anyone reads this, please reopen. The fundamental issue is still unresolved, right?

[davelab6]

@marnen fontforge is basically unmaintained today. Please consider using @trufont instead :)

[marnen]

@davelab6 I did consider it. Unfortunately, TruFont doesn't work very well, at least on Mac OS. FontForge is still more stable and capable. I'd love to get away from George Williams' pile of hacks with a bad attitude, but FontForge is still the most capable OSS font editor out there.

[davelab6]

TruFont will work better sooner with more contributors :)

[marnen]

@davelab6 I'd contribute, but I know very little about developing native desktop applications (I'm a Web developer), and not that much about digital typography either. I'll see what I can do, though...I'd really like it to work.

[davelab6]

You might also be interested in @metapolator then :)

[marnen]

@davelab6 I might indeed. :)