-
Notifications
You must be signed in to change notification settings - Fork 694
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option needed to 'Save' as UFO #669
Comments
What's wrong with Generating ufo? |
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'. |
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 :) |
On Mon, 19 Aug 2013, vernon adams wrote:
This opens the same can of worms opened by the GIMP 2.8 save/export At the moment, when FontForge "saves," that always means SFD. Saving in The justification for doing it the current way (I wasn't around when this So it's a bad thing if the user is encouraged to unknowingly use a format Separating out "generate" has a minor benefit of making the UI coding I think that the way these things currently work in FontForge is not badly I don't think it is reasonable for "save" to do just SFD or UFO, with all
Users, especially me, hate being told what workflow to use. Even if you In any case, before we do anything that even implies that a UFO-based On implementation: having "what does save mean?" be a setting in a
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 |
On 19 August 2013 12:50, Matthew Skala notifications@github.com wrote:
The reason is that UFO is a 'source form' format, like SFD; all the others However, I like the reasoning that the GIMP team have for the difference |
"With scripting you can make a call to xxxx" |
If you look at what I've asked @monkeyiq to work on, its stuff that users |
"Users, especially me, hate being told what workflow to use." "I haven't been |
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. |
I think native/non native is the gimp argument? :-) |
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 :) |
It seems to me, with UFO being promoted as an interchange format for font 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 If we look at it as being neither native FF format nor a usable compiled On Mon, Aug 19, 2013 at 10:17 AM, Matthew Skala notifications@github.comwrote:
Jason Pagura |
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 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. |
On 19 August 2013 16:10, vernon adams notifications@github.com wrote:
You can create the functionality you want with Using the Mac app, hit If you compile FF with Homebrew and get Python scripting, you can unbind https://gist.github.com/davelab6/6362877 (update: @vernnobile confirmed this works) |
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. |
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? |
One, it seems like there is not any will to make UFO a second native
|
OK, so that Open dialog filter omission is a separate issue |
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. |
Please read the original issue submission. This is NOT about forcing
|
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. |
When I go to Generate Fonts, I expect whatever outputs from that to be a On Tue, Aug 27, 2013 at 8:52 AM, Matthew Skala notifications@github.comwrote:
Jason Pagura |
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:
|
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. |
While we're at this, why is "Generate Mac family" a separate menu option? |
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. |
On 27 August 2013 19:24, vernon adams notifications@github.com wrote:
I explained how to set this up already? :) |
On 27 August 2013 20:04, Khaled Hosny notifications@github.com wrote:
|
I fixed it, it had some deps missing |
Hmm it just crashes
|
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...
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. |
For reference, this is what brew installed in the process of installing fontforge, and what the macports machine is using. Brew pango
macports pango
|
oh, and this is the install command I used to trigger the pango (just for reference while it is still in up arrow history)
|
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. |
The only reason for Pango and Cairo not to be hard dependencies seems to be On Mon, Sep 9, 2013 at 10:30 PM, monkeyiq notifications@github.com wrote:
Jason Pagura |
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.
|
@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:
You should be able to rm that symlink and use the above in your However, when I run FF, I get the open dialog, I click "new" and then click the "A" glyph and get this crash:
|
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) |
It seems opening the metrics window already worked. Hopefully that gets the brew'ed fontforge working for folks ;) |
Seems the ' Based on source from git with hash:' line is broken...
|
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. |
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. |
OK thats a pity |
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 versions of some libs I have installed: gcc -v gives |
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. |
Now it works for me. :) |
Hold on, what issue did we just fix? This started on adding UFO as a "Save On Tue, Sep 17, 2013 at 1:09 PM, Dave Crossland notifications@github.comwrote:
Jason Pagura |
@ultrasquid Agreed. If anyone reads this, please reopen. The fundamental issue is still unresolved, right? |
@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. |
TruFont will work better sooner with more contributors :)
|
@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. |
You might also be interested in @metapolator then :)
|
@davelab6 I might indeed. :) |
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
:-)
The text was updated successfully, but these errors were encountered: