Prepare for 0.4.0 #122
Prepare for 0.4.0 #122
Conversation
This bumps the version and also reworks a bunch of docs.
| @@ -545,6 +553,7 @@ impl std::default::Default for AffineTransform { | |||
| } | |||
| } | |||
|
|
|||
| /// An image included in a glyph. | |||
There was a problem hiding this comment.
@ctrlcctrlv when I was adding these docs I remembered you mentioning that the 'image' in a .glif isn't for a background image, but is for image fonts, but then I got very confused looking at the ufo spec, in particular this example, which sure looks like it's describing an image that is being traced over? or something?
Genuinely curious about this, if you have any more information...
There was a problem hiding this comment.
Image means background image for tracing, yes. There was a kerfuffle over this somewhere in the UFO spec issue tracker.
There was a problem hiding this comment.
It means both.
It's clear that the way <image> works isn't only thinking about tracing. If so, the limitation to one image, and the bizarre procedure for colored images, (which I've implemented in glifparser,) is superfluous.
The CBLC table contains a u32 field, colorRef, which I think was envisioned to have a purpose equal to .glif <image> color.
Furthermore, discussions on using <image> to support SVG, currently open (unified-font-object/ufo-spec#104), make no sense if it's not for emoji/color fonts.
The reason I made the sweeping statement is because think about it…there's no way to set an image as a background image/invisible, right? So, that means, if you include an image for tracing, and fontmake or whatever UFO compiler you use compiles your font, it has no way of knowing your intent. Both options are bad: ① throw away the image assuming it was meant for tracing ② keep the image, assuming it was meant for emoji. You can't use the existence of outlines to help, either, because sbix table contains a way to draw outlines over images in its flags bit 1. So no heuristic is gonna work here for all cases.
So, given this is the case, no sane user is going to use the <image> tag for anything but output images, especially in the default glyphs directory. If a dual use was envisioned, the UFO spec should have specified!
There was a problem hiding this comment.
Okay, I can definitely see how this is, at the very least, ambiguous.
I guess my main practical question would be: is anyone actually designing colour fonts using UFO?
In any case, I can see that if you want images for tracing, putting putting them in a separate layer (but maybe still using the image field?) makes sense.
Thanks both!
There was a problem hiding this comment.
Disagree with @ctrlcctrlv's conclusion; if you look at it either from an ahistorical view or by not looking at what other tools that use the UFO do, then that could be a valid conclusion. But viewed by common practice and what was going on when UFO3 was specified: right now the main use of <image> is for things in the background for drawing on top of.
Use of <image> for color fonts is possible (I've done it), but not well supported and depends on a custom toolchain/knowlege that the font intends for this. Going by common use, best to assume for tracing, not for font making.
This is a blindspot in the UFO format that needs correction, spec language for UFO4 very welcome here; especially as it now seems like specs for color fonts have settled down and are unlikely to change much in the future.
There was a problem hiding this comment.
I disagree with your conclusion, so that makes two of us :-)
I want my UFO's to be future-proof. Definitely I wouldn't (won't) be sticking an ambiguous <image> in there for current or future software to do whatever it wants with.
MFEKglif simply warns users, trying to get them to put images in any layer but layer 0 (glif foreground, == <outline>, <component>, <image>, etc.), and mentions the ambiguity of not doing so. (MFEKglif is written such that if you want other layers to be available in the standard UFO format, that requires a utility to "split" the layers out of a .glif's <lib/>/<MFEK/> which I haven't written yet.)
There was a problem hiding this comment.
having caught up on the, ahem, 'historical literature', I think we can agree that:
<image>was originally intended for template images.- This is not clearly communicated in the spec
- Some people have used
<image>to store image data for colour fonts - This ambiguity is bad
I think the only real way to have clarity here is with an update to the spec. In the meantime when confronted with an <image> field, devoid of other context, I think the reasonable assumption is that it is a tracing image, and I do think, in the absence of changes to the spec, I would personally support the convention of storing tracing images in a non-default layer. 🤷
There was a problem hiding this comment.
@cmyr This is logical, think your solution is good. By ahistorical (as I detect some sarcasm there 😉) I meant that the UFO3 spec was 2012, there wasn't a standard color font spec until 2016. It's hard for a spec to predict the future...
There was a problem hiding this comment.
@benkiel ha actually my 'historical literature' reference was at least not consciously referring to your use of 'ahistorical'! In any case, no argument from me that predicting the future is hard, or that authoring specs in general is hard.
This bumps the version and also reworks a bunch of docs.