Serious spec problem: custom XML inside GLIF lib data element
53 views
Skip to first unread message
Adam Twardoch (List)
Dec 9, 2014, 1:33:59 AM12/9/14
to ufo-...@googlegroups.com
Dear UFO spec community,
In April-September 2013, Adobe has proposed its UFO extension to store PostScript hints. The discussion can be found at:
https://groups.google.com/d/topic/ufo-spec/mRlcDYg6Shg/discussion
https://groups.google.com/d/topic/ufo-spec/7toFE5w9Y0g/discussion
The method is now implemented in AFDKO:
https://github.com/adobe-type-tools/afdko
The method stores hinting information inside of the GLIF lib under the <key>com.adobe.type.autohint</key> as in:
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<data>
<hintSetList>
<hintset pointTag="ab02">
<hstem pos="-14" width="211" />
<hstem pos="455" width="180" />
<hstem pos="856" width="211" />
<vstem pos="74" width="336" />
<vstem pos="819" width="336" />
</hintset>
<hintset pointTag="hr02">
<hstem pos="21" width="-21" />
<hstem pos="455" width="180" />
<hstem pos="739" width="328" />
<vstem pos="74" width="336" />
<vstem pos="850" width="305" />
</hintset>
</hintSetList>
</data>
</dict>
</lib>
As you will notice, the <data> section contains custom XML which is outside the namespace defined by the Apple plist.
THIS IS A PROBLEM.
The GLIF spec http://unifiedfontobject.org/versions/ufo3/glif.html says:
"lib: Custom data storage. This element is a place to store authoring tool specific, user specific or otherwise arbitrary data for the glyph. lib mus have one child element that is structure as a dictionary formatted as an XML Property List."
The http://unifiedfontobject.org/versions/ufo3/conventions.html#propertylist document links to the XML Property List (plist) DTD:
http://www.apple.com/DTDs/PropertyList-1.0.dtd
That DTD clearly says:
<!ELEMENT data (#PCDATA)> <!-- Contents interpreted as Base-64 encoded -->
This means that in fact, the above <data> section of any entry in the GLIF lib should be written like this:
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<data>
ICA8aGludFNldExpc3Q+CiAgICA8aGludHNldCBwb2ludFRhZz0iYWIwMi
I+CiAgICAgIDxoc3RlbSBwb3M9Ii0xNCIgd2lkdGg9IjIxMSIgLz4KICAg
ICAgPGhzdGVtIHBvcz0iNDU1IiB3aWR0aD0iMTgwIiAvPgogICAgICA8aH
N0ZW0gcG9zPSI4NTYiIHdpZHRoPSIyMTEiIC8+CiAgICAgIDx2c3RlbSBw
b3M9Ijc0IiB3aWR0aD0iMzM2IiAvPgogICAgICA8dnN0ZW0gcG9zPSI4MT
kiIHdpZHRoPSIzMzYiIC8+CiAgICA8L2hpbnRzZXQ+CiAgICA8aGludHNl
dCBwb2ludFRhZz0iaHIwMiI+CiAgICAgIDxoc3RlbSBwb3M9IjIxIiB3aW
R0aD0iLTIxIiAvPgogICAgICA8aHN0ZW0gcG9zPSI0NTUiIHdpZHRoPSIx
ODAiIC8+CiAgICAgIDxoc3RlbSBwb3M9IjczOSIgd2lkdGg9IjMyOCIgLz
4KICAgICAgPHZzdGVtIHBvcz0iNzQiIHdpZHRoPSIzMzYiIC8+CiAgICAg
IDx2c3RlbSBwb3M9Ijg1MCIgd2lkdGg9IjMwNSIgLz4KICAgIDwvaGludH
NldD4KICA8L2hpbnRTZXRMaXN0Pgo=
</data>
</dict>
</lib>
Otherwise, the lib section inside the GLIF is not a valid plist!
Fortunately, the GLIF file itself is not a plist, so there should be no strict requirement that the stuff inside the data element of the lib should adhere to plist conventions.
As Adobe showed, the requirement to base64-encode contents of the data element is just impractical.
However, implementations are at risk. It seems that RoboFont does not quite well deal with any custom XML inside the lib's data element, it requires that the contents of the lib data element must be base64-encoded. On the other hand, AFDKO writes GLIF files where the contents of the lib data element is NOT base64-encoded.
At FontLab, we're using a similar approach to Adobe: we're using the lib data to store our TTH (visual TrueType hinting) info. The human-readable version is like this:
<lib>
<dict>
<key>com.fontlab.ttprogram</key>
<data>
<ttProgram>
<ttc code="doubleh" point1="dh01" point2="dh02"/>
<ttc code="mdeltah" point="dh02" delta="-8" ppm1="24" ppm2="24"/>
<ttc code="mdeltah" point="dh02" delta="8" ppm1="9" ppm2="9"/>
<ttc code="mdeltah" point="dh02" delta="-8" ppm1="14" ppm2="14"/>
<ttc code="mdeltah" point="dh02" delta="-8" ppm1="12" ppm2="12"/>
<ttc code="singleh" point1="dh02" point2="sh01" stem="X: 95"/>
</ttProgram>
</data>
</dict>
</lib>
But according to the strict GLIF spec, we'd have to store it like this:
<lib>
<dict>
<key>com.fontlab.ttprogram</key>
<data>
ICA8dHRQcm9ncmFtPgogICAgPHR0YyBjb2RlPSJkb3VibGVoIiBwb2ludD
E9ImRoMDEiIHBvaW50Mj0iZGgwMiIvPgogICAgPHR0YyBjb2RlPSJtZGVs
dGFoIiBwb2ludD0iZGgwMiIgZGVsdGE9Ii04IiBwcG0xPSIyNCIgcHBtMj
0iMjQiLz4KICAgIDx0dGMgY29kZT0ibWRlbHRhaCIgcG9pbnQ9ImRoMDIi
IGRlbHRhPSI4IiBwcG0xPSI5IiBwcG0yPSI5Ii8+CiAgICA8dHRjIGNvZG
U9Im1kZWx0YWgiIHBvaW50PSJkaDAyIiBkZWx0YT0iLTgiIHBwbTE9IjE0
IiBwcG0yPSIxNCIvPgogICAgPHR0YyBjb2RlPSJtZGVsdGFoIiBwb2ludD
0iZGgwMiIgZGVsdGE9Ii04IiBwcG0xPSIxMiIgcHBtMj0iMTIiLz4KICAg
IDx0dGMgY29kZT0ic2luZ2xlaCIgcG9pbnQxPSJkaDAyIiBwb2ludDI9In
NoMDEiIHN0ZW09Ilg6IDk1Ii8+CiAgPC90dFByb2dyYW0+Cg==
</data>
</dict>
</lib>
Currently, our vfb2ufo converter has a "-64" commandline switch.
If the switch is supplied, the data for both PostScript hinting (using <key>com.adobe.type.autohint</key>) and TrueType hinting (using <key>com.fontlab.ttprogram</key>) is written as base64-encoded.
If the switch is not supplied, both kinds of info are written in human-readable form (i.e. custom XML inside the <data> element).
When reading GLIF lib data, we automatically detect both flavors.
So the problem is:
1. Some implementations (RoboFont) rely on the fact that anything inside a GLIF lib data element is base64-encoded.
2. Some implementations (AFDKO) write custom XML inside a GLIF lib data element that is NOT base64-encoded.
3. The notation introduced by Adobe has been discussed here a year ago, and it was accepted by the UFO spec authors. (I was not aware of the plist requirement at the time, or I would have raised it back then). So while the non-base64 contents of GLIF lib data is against the spec, it has been sort-of authorized by the UFO spec community, but implementations struggle (and will continue to struggle) with this.
4. The base64-encoded representation of the GLIF lib data is ugly, non-readable and kind of defeats lots of purposes of UFO. It's tedious to work with.
5. The current form of human-readable <data> contents as used by Adobe (and, at this time, FontLab) is NOT VERY GOOD because it makes it virtually impossible to produce any kind of schema for the GLIF XML that would be valid. The GLIF XML should ultimately have a schema with a clearly defined set of permissible elements.
At FontLab, we'd prefer if the requirement to base-64 encode the contents of the <data> element inside a GLIF lib was lifted. However, the current method that Adobe uses is not good either.
The proper way to do it using XML would be that each vendor would reserve a custom XML namespace prefix (which could be referred by a namespace declaration if needed).
So, a serious implementation would look like this:
<?xml version="1.0" encoding="UTF-8"?>
<glyph name="o" format="1" xmlns="http://unifiedfontobject.org"
xmlns:adobe="http://type.adobe.com"
xmlns:fontlab="http://fontlab.com">
(...)
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<data>
<adobe:hintSetList>
<adobe:hintset pointTag="ab02">
<adobe:hstem pos="-14" width="211" />
<adobe:hstem pos="455" width="180" />
<adobe:hstem pos="856" width="211" />
<adobe:vstem pos="74" width="336" />
<adobe:vstem pos="819" width="336" />
</adobe:hintset>
<adobe:hintset pointTag="hr02">
<adobe:hstem pos="21" width="-21" />
<adobe:hstem pos="455" width="180" />
<adobe:hstem pos="739" width="328" />
<adobe:vstem pos="74" width="336" />
<adobe:vstem pos="850" width="305" />
</adobe:hintset>
</adobe:hintSetList>
</data>
</dict>
<dict>
<key>com.fontlab.ttprogram</key>
<data>
<fontlab:ttProgram>
<fontlab:ttc code="doubleh" point1="dh01" point2="dh02"/>
<fontlab:ttc code="mdeltah" point="dh02" delta="-8" ppm1="24" ppm2="24"/>
<fontlab:ttc code="mdeltah" point="dh02" delta="8" ppm1="9" ppm2="9"/>
<fontlab:ttc code="mdeltah" point="dh02" delta="-8" ppm1="14" ppm2="14"/>
<fontlab:ttc code="mdeltah" point="dh02" delta="-8" ppm1="12" ppm2="12"/>
<fontlab:ttc code="singleh" point1="dh02" point2="sh01" stem="X: 95"/>
</fontlab:ttProgram>
</data>
</dict>
</lib>
Note that the URIs used in the xmlns attributes do NOT have to be valid URLs. It's more like a convention, and the convention should be to "unreverse" the reversed domain notation and cut it at some point, e.g. at the level of a vendor. See http://en.wikipedia.org/wiki/XML_namespace or http://docstore.mik.ua/orelly/xml/schema/ch10_06.htm
AFAIK, the example I show above would be a structurally valid XML.
It would still not make the <lib> section to adhere to Apple's plist DTD, but this should not be a requirement, since the GLIF XML as a whole is not an Apple plist either.
I would very much appreciate comments and pointers towards resolving this.
Best,
Adam
In April-September 2013, Adobe has proposed its UFO extension to store PostScript hints. The discussion can be found at:
https://groups.google.com/d/topic/ufo-spec/mRlcDYg6Shg/discussion
https://groups.google.com/d/topic/ufo-spec/7toFE5w9Y0g/discussion
The method is now implemented in AFDKO:
https://github.com/adobe-type-tools/afdko
The method stores hinting information inside of the GLIF lib under the <key>com.adobe.type.autohint</key> as in:
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<data>
<hintSetList>
<hintset pointTag="ab02">
<hstem pos="-14" width="211" />
<hstem pos="455" width="180" />
<hstem pos="856" width="211" />
<vstem pos="74" width="336" />
<vstem pos="819" width="336" />
</hintset>
<hintset pointTag="hr02">
<hstem pos="21" width="-21" />
<hstem pos="455" width="180" />
<hstem pos="739" width="328" />
<vstem pos="74" width="336" />
<vstem pos="850" width="305" />
</hintset>
</hintSetList>
</data>
</dict>
</lib>
As you will notice, the <data> section contains custom XML which is outside the namespace defined by the Apple plist.
THIS IS A PROBLEM.
The GLIF spec http://unifiedfontobject.org/versions/ufo3/glif.html says:
"lib: Custom data storage. This element is a place to store authoring tool specific, user specific or otherwise arbitrary data for the glyph. lib mus have one child element that is structure as a dictionary formatted as an XML Property List."
The http://unifiedfontobject.org/versions/ufo3/conventions.html#propertylist document links to the XML Property List (plist) DTD:
http://www.apple.com/DTDs/PropertyList-1.0.dtd
That DTD clearly says:
<!ELEMENT data (#PCDATA)> <!-- Contents interpreted as Base-64 encoded -->
This means that in fact, the above <data> section of any entry in the GLIF lib should be written like this:
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<data>
ICA8aGludFNldExpc3Q+CiAgICA8aGludHNldCBwb2ludFRhZz0iYWIwMi
I+CiAgICAgIDxoc3RlbSBwb3M9Ii0xNCIgd2lkdGg9IjIxMSIgLz4KICAg
ICAgPGhzdGVtIHBvcz0iNDU1IiB3aWR0aD0iMTgwIiAvPgogICAgICA8aH
N0ZW0gcG9zPSI4NTYiIHdpZHRoPSIyMTEiIC8+CiAgICAgIDx2c3RlbSBw
b3M9Ijc0IiB3aWR0aD0iMzM2IiAvPgogICAgICA8dnN0ZW0gcG9zPSI4MT
kiIHdpZHRoPSIzMzYiIC8+CiAgICA8L2hpbnRzZXQ+CiAgICA8aGludHNl
dCBwb2ludFRhZz0iaHIwMiI+CiAgICAgIDxoc3RlbSBwb3M9IjIxIiB3aW
R0aD0iLTIxIiAvPgogICAgICA8aHN0ZW0gcG9zPSI0NTUiIHdpZHRoPSIx
ODAiIC8+CiAgICAgIDxoc3RlbSBwb3M9IjczOSIgd2lkdGg9IjMyOCIgLz
4KICAgICAgPHZzdGVtIHBvcz0iNzQiIHdpZHRoPSIzMzYiIC8+CiAgICAg
IDx2c3RlbSBwb3M9Ijg1MCIgd2lkdGg9IjMwNSIgLz4KICAgIDwvaGludH
NldD4KICA8L2hpbnRTZXRMaXN0Pgo=
</data>
</dict>
</lib>
Otherwise, the lib section inside the GLIF is not a valid plist!
Fortunately, the GLIF file itself is not a plist, so there should be no strict requirement that the stuff inside the data element of the lib should adhere to plist conventions.
As Adobe showed, the requirement to base64-encode contents of the data element is just impractical.
However, implementations are at risk. It seems that RoboFont does not quite well deal with any custom XML inside the lib's data element, it requires that the contents of the lib data element must be base64-encoded. On the other hand, AFDKO writes GLIF files where the contents of the lib data element is NOT base64-encoded.
At FontLab, we're using a similar approach to Adobe: we're using the lib data to store our TTH (visual TrueType hinting) info. The human-readable version is like this:
<lib>
<dict>
<key>com.fontlab.ttprogram</key>
<data>
<ttProgram>
<ttc code="doubleh" point1="dh01" point2="dh02"/>
<ttc code="mdeltah" point="dh02" delta="-8" ppm1="24" ppm2="24"/>
<ttc code="mdeltah" point="dh02" delta="8" ppm1="9" ppm2="9"/>
<ttc code="mdeltah" point="dh02" delta="-8" ppm1="14" ppm2="14"/>
<ttc code="mdeltah" point="dh02" delta="-8" ppm1="12" ppm2="12"/>
<ttc code="singleh" point1="dh02" point2="sh01" stem="X: 95"/>
</ttProgram>
</data>
</dict>
</lib>
But according to the strict GLIF spec, we'd have to store it like this:
<lib>
<dict>
<key>com.fontlab.ttprogram</key>
<data>
ICA8dHRQcm9ncmFtPgogICAgPHR0YyBjb2RlPSJkb3VibGVoIiBwb2ludD
E9ImRoMDEiIHBvaW50Mj0iZGgwMiIvPgogICAgPHR0YyBjb2RlPSJtZGVs
dGFoIiBwb2ludD0iZGgwMiIgZGVsdGE9Ii04IiBwcG0xPSIyNCIgcHBtMj
0iMjQiLz4KICAgIDx0dGMgY29kZT0ibWRlbHRhaCIgcG9pbnQ9ImRoMDIi
IGRlbHRhPSI4IiBwcG0xPSI5IiBwcG0yPSI5Ii8+CiAgICA8dHRjIGNvZG
U9Im1kZWx0YWgiIHBvaW50PSJkaDAyIiBkZWx0YT0iLTgiIHBwbTE9IjE0
IiBwcG0yPSIxNCIvPgogICAgPHR0YyBjb2RlPSJtZGVsdGFoIiBwb2ludD
0iZGgwMiIgZGVsdGE9Ii04IiBwcG0xPSIxMiIgcHBtMj0iMTIiLz4KICAg
IDx0dGMgY29kZT0ic2luZ2xlaCIgcG9pbnQxPSJkaDAyIiBwb2ludDI9In
NoMDEiIHN0ZW09Ilg6IDk1Ii8+CiAgPC90dFByb2dyYW0+Cg==
</data>
</dict>
</lib>
Currently, our vfb2ufo converter has a "-64" commandline switch.
If the switch is supplied, the data for both PostScript hinting (using <key>com.adobe.type.autohint</key>) and TrueType hinting (using <key>com.fontlab.ttprogram</key>) is written as base64-encoded.
If the switch is not supplied, both kinds of info are written in human-readable form (i.e. custom XML inside the <data> element).
When reading GLIF lib data, we automatically detect both flavors.
So the problem is:
1. Some implementations (RoboFont) rely on the fact that anything inside a GLIF lib data element is base64-encoded.
2. Some implementations (AFDKO) write custom XML inside a GLIF lib data element that is NOT base64-encoded.
3. The notation introduced by Adobe has been discussed here a year ago, and it was accepted by the UFO spec authors. (I was not aware of the plist requirement at the time, or I would have raised it back then). So while the non-base64 contents of GLIF lib data is against the spec, it has been sort-of authorized by the UFO spec community, but implementations struggle (and will continue to struggle) with this.
4. The base64-encoded representation of the GLIF lib data is ugly, non-readable and kind of defeats lots of purposes of UFO. It's tedious to work with.
5. The current form of human-readable <data> contents as used by Adobe (and, at this time, FontLab) is NOT VERY GOOD because it makes it virtually impossible to produce any kind of schema for the GLIF XML that would be valid. The GLIF XML should ultimately have a schema with a clearly defined set of permissible elements.
At FontLab, we'd prefer if the requirement to base-64 encode the contents of the <data> element inside a GLIF lib was lifted. However, the current method that Adobe uses is not good either.
The proper way to do it using XML would be that each vendor would reserve a custom XML namespace prefix (which could be referred by a namespace declaration if needed).
So, a serious implementation would look like this:
<?xml version="1.0" encoding="UTF-8"?>
<glyph name="o" format="1" xmlns="http://unifiedfontobject.org"
xmlns:adobe="http://type.adobe.com"
xmlns:fontlab="http://fontlab.com">
(...)
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<data>
<adobe:hintSetList>
<adobe:hintset pointTag="ab02">
<adobe:hstem pos="-14" width="211" />
<adobe:hstem pos="455" width="180" />
<adobe:hstem pos="856" width="211" />
<adobe:vstem pos="74" width="336" />
<adobe:vstem pos="819" width="336" />
</adobe:hintset>
<adobe:hintset pointTag="hr02">
<adobe:hstem pos="21" width="-21" />
<adobe:hstem pos="455" width="180" />
<adobe:hstem pos="739" width="328" />
<adobe:vstem pos="74" width="336" />
<adobe:vstem pos="850" width="305" />
</adobe:hintset>
</adobe:hintSetList>
</data>
</dict>
<dict>
<key>com.fontlab.ttprogram</key>
<data>
<fontlab:ttProgram>
<fontlab:ttc code="doubleh" point1="dh01" point2="dh02"/>
<fontlab:ttc code="mdeltah" point="dh02" delta="-8" ppm1="24" ppm2="24"/>
<fontlab:ttc code="mdeltah" point="dh02" delta="8" ppm1="9" ppm2="9"/>
<fontlab:ttc code="mdeltah" point="dh02" delta="-8" ppm1="14" ppm2="14"/>
<fontlab:ttc code="mdeltah" point="dh02" delta="-8" ppm1="12" ppm2="12"/>
<fontlab:ttc code="singleh" point1="dh02" point2="sh01" stem="X: 95"/>
</fontlab:ttProgram>
</data>
</dict>
</lib>
Note that the URIs used in the xmlns attributes do NOT have to be valid URLs. It's more like a convention, and the convention should be to "unreverse" the reversed domain notation and cut it at some point, e.g. at the level of a vendor. See http://en.wikipedia.org/wiki/XML_namespace or http://docstore.mik.ua/orelly/xml/schema/ch10_06.htm
AFAIK, the example I show above would be a structurally valid XML.
It would still not make the <lib> section to adhere to Apple's plist DTD, but this should not be a requirement, since the GLIF XML as a whole is not an Apple plist either.
I would very much appreciate comments and pointers towards resolving this.
Best,
Adam
Tal Leming
Dec 9, 2014, 7:34:19 AM12/9/14
to ufo-...@googlegroups.com
In April-September 2013, Adobe has proposed its UFO extension to store PostScript hints. The discussion can be found at:
https://groups.google.com/d/topic/ufo-spec/mRlcDYg6Shg/discussion
https://groups.google.com/d/topic/ufo-spec/7toFE5w9Y0g/discussion
Please be sure not to skip the first section of my comments on May 15, 2013.
Fortunately, the GLIF file itself is not a plist, so there should be no strict requirement that the stuff inside the data element of the lib should adhere to plist conventions.
No, it is extremely important that it strictly follow the Property List DTD. The data element is a last resort for situations when an object can't be serialized into the regular Property List data structure. I didn't invent PLIST, so I can only guess, but I'm pretty sure that data exists so that bits of binary, like images, can be included.
However, implementations are at risk. It seems that RoboFont does not quite well deal with any custom XML inside the lib's data element, it requires that the contents of the lib data element must be base64-encoded.
It's not just RoboFont, it's anything that uses ufoLib. That uses a DTD compliant PLIST reader. Anything that follows the spec/DTD is going to have a problem with anything that doesn't follow the spec/DTD.
3. The notation introduced by Adobe has been discussed here a year ago, and it was accepted by the UFO spec authors.
No, it most certainly was not. Please see the first part of my comment on May 15, 2013:
"""
The structure needs to be adjusted so that it can be stored in a property list.
"""
After that I sketched out a structure that was perfectly legal in PLIST *without* needing the data element. (Something that I'm pretty sure that I offered to help you guys with on vfb2ufo as well.)
As the editor of the spec I can't officially intervene into lib matters. The whole point of the lib is, beyond the standardized format, users can put whatever they want in. The only requirement is that they follow the PLIST spec. The UFO spec editors can't be the the lib police. We can only try to nudge in the right direction here and there.
4. The base64-encoded representation of the GLIF lib data is ugly, non-readable and kind of defeats lots of purposes of UFO. It's tedious to work with.
I agree. But, it's a necessary last resort. (FWIW, I've never had to use the data element in 10+ years of heavy UFO work.)
5. The current form of human-readable <data> contents as used by Adobe (and, at this time, FontLab) is NOT VERY GOOD because it makes it virtually impossible to produce any kind of schema for the GLIF XML that would be valid. The GLIF XML should ultimately have a schema with a clearly defined set of permissible elements.
Apart from this particular data design problem, what is wrong with lib? This is the very type of situation it was designed for.
At FontLab, we'd prefer if the requirement to base-64 encode the contents of the <data> element inside a GLIF lib was lifted. However, the current method that Adobe uses is not good either.
This requirement can not be lifted. It would break existing implementations and lead to significant issues. The original intent of the data element, to store binary data, would be subverted. If a blob of binary must be included, how is that going to be safely stored if base64 is not allowed? If it is allowed, but optional, what will the requirements be for when base64 is needed? When the resulting data element would lead to invalid or unparsable XML? That's the very problem that you have run into. Further, if the base64 encoding is optional, readers will have to sniff the incoming text by pushing it through a decoder to see if it can be decoded. If so, it would be assumed to be base64. That's expensive. (Nightmare situation: what if some text is valid base64 but not actually originally base64?)
The proper way to do it using XML would be that each vendor would reserve a custom XML namespace prefix (which could be referred by a namespace declaration if needed).
This is far too complex. All of this information can be represented without the data element. I don't have time to do it right now, but later today I will sketch out how the vfb2ufo data could be represented without base64 and without the data element. I recently did some work with those data structures so I already have a PLIST ready implementation.
Thanks,
Tal
Adam Twardoch (List)
Dec 9, 2014, 8:40:42 AM12/9/14
to ufo-...@googlegroups.com
Hello Tal, :)
I agree that it can be expressed using plist structures.
There is basically a generic translation scheme from normal XML (that uses elements with attributes) to plist XML.
Take the HTML img tag:
<img src="logo.png" width="300" height="100" alt="logo" />
This translates to the plist XML as follows:
<key>img</key>
<dict>
<key>src</key>
<string>logo.png</string>
<key>width</key>
<integer>300</integer>
<key>height</key>
<integer>100</integer>
<key>alt</key>
<string>logo</string>
</dict>
Which is amazingly 3.4x larger and completely unreadable. But surely it can be done. :)
The core GLIF structure itself, i.e.
<?xml version="1.0" encoding="UTF-8"?>
<glyph name="O" format="1">
<advance width="648"/>
<unicode hex="004F"/>
<outline>
<contour identifier="9384209854">
<point x="324" y="-12" type="curve" smooth="yes"/>
<point x="480" y="-12"/>
</contour>
</outline>
</glyph>
could also be expressed in plist XML without a problem:
<key>glyph</key>
<dict>
<key>name</key>
<string>O</string>
<key>format</key>
<integer>1</integer>
<key>advance</key>
<dict>
<key>width</key>
<integer>648</integer>
</dict>
<key>unicode</key>
<dict>
<key>kex</key>
<string>004F</string>
</dict>
<key>outline</key>
<array>
<key>contour</contour>
<dict>
<key>identifier</key>
<string>9384209854</string>
<key>elements</key><!-- PROBLEM -->
<array>
<key>point</key>
<dict>
<key>x</key>
<integer>324</integer>
<key>y</key>
<integer>-12</integer>
<key>type</key>
<string>curve</string>
<key>smooth</key>
<true></true>
</dict>
<key>point</key>
<dict>
<key>x</key>
<integer>480</integer>
<key>y</key>
<integer>-12</integer>
</dict>
</array>
</dict>
</array>
</dict>
I may have made a small mistake here or there in the example above, but the general principle stands. With "<!-- PROBLEM -->", I marked a place where I had to invent a key because I wasn't sure if there is another way to translate this (an array of child elements).
But, generally, it's no problem to express it all in plist XML. Plist XML ist just 1 level more verbose than normal XML because for each XML element you need to make a plist dict, where you store each XML attribute as a key-value pair, enumerating the data type each time. It's about 3x larger than the normal XML and much less human-readable.
There is no problem to express any HTML document, or the Adobe hinting structures, or the FontLab TTH structures, or, in fact, the core GLIF structure, using plist XML. In fact, if the core GLIF structure were expressed using plist XML, I would say that the lib structures also should.
>> In April-September 2013, Adobe has proposed its UFO extension to store PostScript hints. The discussion can be found at:
>>
>> https://groups.google.com/d/topic/ufo-spec/mRlcDYg6Shg/discussion
>> https://groups.google.com/d/topic/ufo-spec/7toFE5w9Y0g/discussion
>
> Please be sure not to skip the first section of my comments on May 15, 2013.
Sorry, you're right. I do see now that you have raised your concerns.
>> Fortunately, the GLIF file itself is not a plist, so there should be no strict requirement that the stuff inside the data element of the lib should adhere to plist conventions.
>
> No, it is extremely important that it strictly follow the Property List DTD. The data element is a last resort for situations when an object can't be serialized into the regular Property List data structure. I didn't invent PLIST, so I can only guess, but I'm pretty sure that data exists so that bits of binary, like images, can be included.
As I have shown above, it is possible to indeed create a pretty-much generic algorithm that will translate all normal XML into plist and back. Plist XML is not real XML because it doesn't use attributes, just elements, so any element with attributes has to be exploded into those verbose dict structures. But it can be done, and in an consistent way.
>> However, implementations are at risk. It seems that RoboFont does not quite well deal with any custom XML inside the lib's data element, it requires that the contents of the lib data element must be base64-encoded.
>
> It's not just RoboFont, it's anything that uses ufoLib. That uses a DTD compliant PLIST reader. Anything that follows the spec/DTD is going to have a problem with anything that doesn't follow the spec/DTD.
I see. So I guess in order to stay compliant, we'd need to urge Adobe and FontLab (i.e. ourselves) to:
a) either always use normal XML hidden inside a base64-encoded <data> element
b) or convert our nice normal XML structures into exploded plist XML as I've shown above
>> 3. The notation introduced by Adobe has been discussed here a year ago, and it was accepted by the UFO spec authors.
>
> No, it most certainly was not. Please see the first part of my comment on May 15, 2013:
>
> """
> The structure needs to be adjusted so that it can be stored in a property list.
> """
>
> After that I sketched out a structure that was perfectly legal in PLIST *without* needing the data element. (Something that I'm pretty sure that I offered to help you guys with on vfb2ufo as well.)
>
> As the editor of the spec I can't officially intervene into lib matters. The whole point of the lib is, beyond the standardized format, users can put whatever they want in. The only requirement is that they follow the PLIST spec. The UFO spec editors can't be the the lib police. We can only try to nudge in the right direction here and there.
I agree that you cannot prevent people from abusing it. :)
I think the problem I have with the whole thing is really that when you use normal XML in the core GLIF but plist XML in lib, then you lose correspondence in the structures.
Currently, with our "bad" TTH format, we have:
<glyph format="1" name="E">
<advance width="590"/>
<unicode hex="0045"/>
<outline>
<contour>
<point name="dh02" type="line" x="527" y="505"/>
<point name="ih01" type="line" x="466" y="360"/>
<point name="sh03" type="line" x="196" y="320"/>
</contour>
</outline>
</ttProgram>
</data>
</dict>
</lib>
</glyph>
The "name" attribute of points in the core GLIF correspond to attributes in the TTH. But if I translate the ttProgram section to plist XML, I'll have:
<glyph format="1" name="E">
<advance width="590"/>
<unicode hex="0045"/>
<outline>
<contour>
<point name="dh02" type="line" x="527" y="505"/>
<point name="ih01" type="line" x="466" y="360"/>
<point name="sh03" type="line" x="196" y="320"/>
</contour>
</outline>
<array>
<key>ttc</key>
<dict>
<key>align</key>
<string>round</string>
<key>code</key>
<string>interpolateh</string>
<key>point</key>
<string>ih01</string>
<key>point1</key>
<string>sh03</string>
<key>point2</key>
<string>dh02</string>
</dict>
</array>
</data>
</dict>
</lib>
</glyph>
In one section of the GLIF, the same data entity (a point name) exists as an XML attribute while in another, it exists as XML *contents*. This is apples and oranges in one.
>> 5. The current form of human-readable <data> contents as used by Adobe (and, at this time, FontLab) is NOT VERY GOOD because it makes it virtually impossible to produce any kind of schema for the GLIF XML that would be valid. The GLIF XML should ultimately have a schema with a clearly defined set of permissible elements.
>
> Apart from this particular data design problem, what is wrong with lib? This is the very type of situation it was designed for.
No no, I like the lib. I may have phrased it wrong. I mean, the lib by itself is fine.
Well, I guess the discussion is really purely notational. I must admit that I find the verbosity of plist XML kind of disgusting. It does have SOME advantages (for example the fact that it does hint at data types so you know where an integer is expected and where a string), but it just feels wrong that the same data exists on two entirely different levels within one file. It's very very unelegant. (As I said, if all of GLIF was written using plist XML as in my initial example, then I would say it's ugly but at least consistently ugly. :)
> This is far too complex. All of this information can be represented without the data element. I don't have time to do it right now, but later today I will sketch out how the vfb2ufo data could be represented without base64 and without the data element. I recently did some work with those data structures so I already have a PLIST ready implementation.
I would argue that my generic translation scheme that I showed above would to the trick, no? But if you have a different structure in mind, please let me know.
That might, in the end, be the reason to introduce into the "com.fontlab.v2.ttprogram" key :D
Best,
Adam
I agree that it can be expressed using plist structures.
There is basically a generic translation scheme from normal XML (that uses elements with attributes) to plist XML.
Take the HTML img tag:
<img src="logo.png" width="300" height="100" alt="logo" />
This translates to the plist XML as follows:
<key>img</key>
<dict>
<key>src</key>
<string>logo.png</string>
<key>width</key>
<integer>300</integer>
<key>height</key>
<integer>100</integer>
<key>alt</key>
<string>logo</string>
</dict>
Which is amazingly 3.4x larger and completely unreadable. But surely it can be done. :)
The core GLIF structure itself, i.e.
<?xml version="1.0" encoding="UTF-8"?>
<advance width="648"/>
<unicode hex="004F"/>
<outline>
<contour identifier="9384209854">
<point x="324" y="-12" type="curve" smooth="yes"/>
<point x="480" y="-12"/>
</contour>
</outline>
</glyph>
could also be expressed in plist XML without a problem:
<key>glyph</key>
<dict>
<key>name</key>
<string>O</string>
<key>format</key>
<integer>1</integer>
<key>advance</key>
<dict>
<key>width</key>
<integer>648</integer>
</dict>
<key>unicode</key>
<dict>
<key>kex</key>
<string>004F</string>
</dict>
<key>outline</key>
<array>
<key>contour</contour>
<dict>
<key>identifier</key>
<string>9384209854</string>
<key>elements</key><!-- PROBLEM -->
<array>
<key>point</key>
<dict>
<key>x</key>
<integer>324</integer>
<key>y</key>
<integer>-12</integer>
<key>type</key>
<string>curve</string>
<key>smooth</key>
<true></true>
</dict>
<key>point</key>
<dict>
<key>x</key>
<integer>480</integer>
<key>y</key>
<integer>-12</integer>
</dict>
</array>
</dict>
</array>
</dict>
I may have made a small mistake here or there in the example above, but the general principle stands. With "<!-- PROBLEM -->", I marked a place where I had to invent a key because I wasn't sure if there is another way to translate this (an array of child elements).
But, generally, it's no problem to express it all in plist XML. Plist XML ist just 1 level more verbose than normal XML because for each XML element you need to make a plist dict, where you store each XML attribute as a key-value pair, enumerating the data type each time. It's about 3x larger than the normal XML and much less human-readable.
There is no problem to express any HTML document, or the Adobe hinting structures, or the FontLab TTH structures, or, in fact, the core GLIF structure, using plist XML. In fact, if the core GLIF structure were expressed using plist XML, I would say that the lib structures also should.
>> In April-September 2013, Adobe has proposed its UFO extension to store PostScript hints. The discussion can be found at:
>>
>> https://groups.google.com/d/topic/ufo-spec/mRlcDYg6Shg/discussion
>> https://groups.google.com/d/topic/ufo-spec/7toFE5w9Y0g/discussion
>
> Please be sure not to skip the first section of my comments on May 15, 2013.
>> Fortunately, the GLIF file itself is not a plist, so there should be no strict requirement that the stuff inside the data element of the lib should adhere to plist conventions.
>
> No, it is extremely important that it strictly follow the Property List DTD. The data element is a last resort for situations when an object can't be serialized into the regular Property List data structure. I didn't invent PLIST, so I can only guess, but I'm pretty sure that data exists so that bits of binary, like images, can be included.
>> However, implementations are at risk. It seems that RoboFont does not quite well deal with any custom XML inside the lib's data element, it requires that the contents of the lib data element must be base64-encoded.
>
> It's not just RoboFont, it's anything that uses ufoLib. That uses a DTD compliant PLIST reader. Anything that follows the spec/DTD is going to have a problem with anything that doesn't follow the spec/DTD.
a) either always use normal XML hidden inside a base64-encoded <data> element
b) or convert our nice normal XML structures into exploded plist XML as I've shown above
>> 3. The notation introduced by Adobe has been discussed here a year ago, and it was accepted by the UFO spec authors.
>
> No, it most certainly was not. Please see the first part of my comment on May 15, 2013:
>
> """
> The structure needs to be adjusted so that it can be stored in a property list.
> """
>
> After that I sketched out a structure that was perfectly legal in PLIST *without* needing the data element. (Something that I'm pretty sure that I offered to help you guys with on vfb2ufo as well.)
>
> As the editor of the spec I can't officially intervene into lib matters. The whole point of the lib is, beyond the standardized format, users can put whatever they want in. The only requirement is that they follow the PLIST spec. The UFO spec editors can't be the the lib police. We can only try to nudge in the right direction here and there.
I think the problem I have with the whole thing is really that when you use normal XML in the core GLIF but plist XML in lib, then you lose correspondence in the structures.
Currently, with our "bad" TTH format, we have:
<glyph format="1" name="E">
<advance width="590"/>
<unicode hex="0045"/>
<outline>
<contour>
<point name="dh02" type="line" x="527" y="505"/>
<point name="ih01" type="line" x="466" y="360"/>
<point name="sh03" type="line" x="196" y="320"/>
</contour>
</outline>
<lib>
<dict>
<key>com.fontlab.ttprogram</key>
<data>
<ttProgram>
<ttc align="round" code="interpolateh" point="ih01" point1="sh03" point2="dh02"/>
<dict>
<key>com.fontlab.ttprogram</key>
<data>
<ttProgram>
</ttProgram>
</data>
</dict>
</lib>
</glyph>
The "name" attribute of points in the core GLIF correspond to attributes in the TTH. But if I translate the ttProgram section to plist XML, I'll have:
<glyph format="1" name="E">
<advance width="590"/>
<unicode hex="0045"/>
<outline>
<contour>
<point name="dh02" type="line" x="527" y="505"/>
<point name="ih01" type="line" x="466" y="360"/>
<point name="sh03" type="line" x="196" y="320"/>
</contour>
</outline>
<lib>
<dict>
<key>com.fontlab.ttprogram</key>
<data>
<key>ttProgram</key>
<dict>
<key>com.fontlab.ttprogram</key>
<data>
<array>
<key>ttc</key>
<dict>
<key>align</key>
<string>round</string>
<key>code</key>
<string>interpolateh</string>
<key>point</key>
<string>ih01</string>
<key>point1</key>
<string>sh03</string>
<key>point2</key>
<string>dh02</string>
</dict>
</array>
</data>
</dict>
</lib>
</glyph>
In one section of the GLIF, the same data entity (a point name) exists as an XML attribute while in another, it exists as XML *contents*. This is apples and oranges in one.
>> 5. The current form of human-readable <data> contents as used by Adobe (and, at this time, FontLab) is NOT VERY GOOD because it makes it virtually impossible to produce any kind of schema for the GLIF XML that would be valid. The GLIF XML should ultimately have a schema with a clearly defined set of permissible elements.
>
> Apart from this particular data design problem, what is wrong with lib? This is the very type of situation it was designed for.
Well, I guess the discussion is really purely notational. I must admit that I find the verbosity of plist XML kind of disgusting. It does have SOME advantages (for example the fact that it does hint at data types so you know where an integer is expected and where a string), but it just feels wrong that the same data exists on two entirely different levels within one file. It's very very unelegant. (As I said, if all of GLIF was written using plist XML as in my initial example, then I would say it's ugly but at least consistently ugly. :)
> This is far too complex. All of this information can be represented without the data element. I don't have time to do it right now, but later today I will sketch out how the vfb2ufo data could be represented without base64 and without the data element. I recently did some work with those data structures so I already have a PLIST ready implementation.
That might, in the end, be the reason to introduce into the "com.fontlab.v2.ttprogram" key :D
Best,
Adam
Lasse Fister
Dec 9, 2014, 9:02:44 AM12/9/14
to ufo-...@googlegroups.com
Hi all,
Another option would be to use a text based serialization format inside
of a plist <string> element. YAML and JSON comes to mind.
<lib>
<dict>
<key>com.fontlab.ttprogram</key>
<string>
ttProgram:
ttc:
align: round
code: interpolateh
point: ih01
point1: sh03
point2: dh02
</string>
</dict>
</lib>
I personally prefer YAML over JSON because it has comments and it is a
superset of JSON. Both are around since a while and there are good
libraries to read and write them.
The plistLib implementations should be able to take care of proper
escaping of special characters for you. I see no reason why this
shouldn't work, but I did not try it.
cheers, Lasse
Another option would be to use a text based serialization format inside
of a plist <string> element. YAML and JSON comes to mind.
<lib>
<dict>
<key>com.fontlab.ttprogram</key>
ttProgram:
ttc:
align: round
code: interpolateh
point: ih01
point1: sh03
point2: dh02
</string>
</dict>
</lib>
I personally prefer YAML over JSON because it has comments and it is a
superset of JSON. Both are around since a while and there are good
libraries to read and write them.
The plistLib implementations should be able to take care of proper
escaping of special characters for you. I see no reason why this
shouldn't work, but I did not try it.
cheers, Lasse
Adam Twardoch (List)
Dec 9, 2014, 9:05:25 AM12/9/14
to ufo-...@googlegroups.com
Ps. I just realized that it's essentially wrong and confusing to be calling the "PlistML" (the Apple XML Property List dialect) "XML".
The PlistML is to normal XML what a children's ride-on is to a car. I mean, it very superficially looks the same, but it's really something very different. I guess people who work with UFO and GLIF need to understand that very deeply. I don't mind the existence of PlistML. I do dislike it, however. I think if fontTools' .ttx output was PlistML and not XML, then TTX wouldn't have gotten off at all. PlistML is far too verbose and is as much human-friendly as WordML used in .docx or other "machine-readable XML dialects".
I think I know (almost -- except the "PROBLEM" section I indicated in my example) how to translate XML to PlistML, and surely it can be done. I guess Adobe FDK needs to be rewritten to support PlistML rather than their own custom XML, and so should our tools (or we should strictly output base64, at least for now). I see that normal XML has no place in GLIF lib. I think it's a pity, but, well, that's UFO. :)
Best,
Adam
> You received this message because you are subscribed to the Google Groups "Unified Font Object Specification" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ufo-spec+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Adam Twardoch (List)
Dec 9, 2014, 9:09:25 AM12/9/14
to ufo-...@googlegroups.com
Sure, that's a possibility. But I think that's as much a dirty hack as base64.
It requires people to learn a yet another dialect. It's like mixing Markdown, Textile, MathML and HTML in one document...
You completely lose structural integrity, any correspondence between the identifiers used in the core GLIF section and the stuff in the lib -- and that's the whole point of the exercise.
I wouldn't mind to have a completely new format which could be YAML, it could even be just a full functional translation of UFO. But I wouldn't want to mix.
A.
It requires people to learn a yet another dialect. It's like mixing Markdown, Textile, MathML and HTML in one document...
You completely lose structural integrity, any correspondence between the identifiers used in the core GLIF section and the stuff in the lib -- and that's the whole point of the exercise.
I wouldn't mind to have a completely new format which could be YAML, it could even be just a full functional translation of UFO. But I wouldn't want to mix.
A.
Adam Twardoch (List)
Dec 9, 2014, 9:43:51 AM12/9/14
to ufo-...@googlegroups.com
I may have made some mistakes in my hand-written PlistML examples before, but I think I'm getting a hand out of it. So, for the PostScript hints information, which is currently stored as:
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<data>
<hintSetList>
<hintset pointTag="ab02">
<hstem pos="-14" width="211" />
<hstem pos="455" width="180" />
<hstem pos="856" width="211" />
<vstem pos="74" width="336" />
<vstem pos="819" width="336" />
</hintset>
<hintset pointTag="hr02">
<hstem pos="21" width="-21" />
<hstem pos="455" width="180" />
<hstem pos="739" width="328" />
<vstem pos="74" width="336" />
<vstem pos="850" width="305" />
</hintset>
</hintSetList>
</data>
</dict>
</lib>
we have one option, which is to encode it as base64:
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<data>ICA8aGludFNldExpc3Q+CiAgICA8aGludHNldCBwb2ludFRhZz0iYWIwMi
I+CiAgICAgIDxoc3RlbSBwb3M9Ii0xNCIgd2lkdGg9IjIxMSIgLz4KICAg
ICAgPGhzdGVtIHBvcz0iNDU1IiB3aWR0aD0iMTgwIiAvPgogICAgICA8aH
N0ZW0gcG9zPSI4NTYiIHdpZHRoPSIyMTEiIC8+CiAgICAgIDx2c3RlbSBw
b3M9Ijc0IiB3aWR0aD0iMzM2IiAvPgogICAgICA8dnN0ZW0gcG9zPSI4MT
kiIHdpZHRoPSIzMzYiIC8+CiAgICA8L2hpbnRzZXQ+CiAgICA8aGludHNl
dCBwb2ludFRhZz0iaHIwMiI+CiAgICAgIDxoc3RlbSBwb3M9IjIxIiB3aW
R0aD0iLTIxIiAvPgogICAgICA8aHN0ZW0gcG9zPSI0NTUiIHdpZHRoPSIx
ODAiIC8+CiAgICAgIDxoc3RlbSBwb3M9IjczOSIgd2lkdGg9IjMyOCIgLz
4KICAgICAgPHZzdGVtIHBvcz0iNzQiIHdpZHRoPSIzMzYiIC8+CiAgICAg
IDx2c3RlbSBwb3M9Ijg1MCIgd2lkdGg9IjMwNSIgLz4KICAgIDwvaGludH
NldD4KICA8L2hpbnRTZXRMaXN0Pgo=
</data>
</dict>
</lib>
or the other, to convert it into PlistML, which, AFAIK, could go like this:
<lib>
<dict>
<key>com.adobe.type.v2.autohint</key>
<dict>
<key>hintSetList</key>
<array>
<dict>
<key>element</key>
<string>hintset</string>
<key>pointTag</key>
<string>ab02</string>
<key>elements</key>
<array>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>-14</integer>
<key>width</key>
<integer>211</integer>
</dict>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>455</integer>
<key>width</key>
<integer>180</integer>
</dict>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>856</integer>
<key>width</key>
<integer>211</integer>
</dict>
<dict>
<key>element</key>
<string>vstem</string>
<key>pos</key>
<integer>74</integer>
<key>width</key>
<integer>336</integer>
</dict>
<dict>
<key>element</key>
<string>vstem</string>
<key>pos</key>
<integer>819</integer>
<key>width</key>
<integer>336</integer>
</dict>
</array>
</dict>
<dict>
<key>element</key>
<string>hintset</string>
<key>pointTag</key>
<string>hr02</string>
<key>elements</key>
<array>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>21</integer>
<key>width</key>
<integer>-21</integer>
</dict>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>455</integer>
<key>width</key>
<integer>180</integer>
</dict>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>739</integer>
<key>width</key>
<integer>328</integer>
</dict>
<dict>
<key>element</key>
<string>vstem</string>
<key>pos</key>
<integer>74</integer>
<key>width</key>
<integer>336</integer>
</dict>
<dict>
<key>element</key>
<string>vstem</string>
<key>pos</key>
<integer>850</integer>
<key>width</key>
<integer>305</integer>
</lib>
Is that correct?
A.
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<data>
<hintSetList>
<hintset pointTag="ab02">
<hstem pos="-14" width="211" />
<hstem pos="455" width="180" />
<hstem pos="856" width="211" />
<vstem pos="74" width="336" />
<vstem pos="819" width="336" />
</hintset>
<hintset pointTag="hr02">
<hstem pos="21" width="-21" />
<hstem pos="455" width="180" />
<hstem pos="739" width="328" />
<vstem pos="74" width="336" />
<vstem pos="850" width="305" />
</hintset>
</hintSetList>
</data>
</dict>
</lib>
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<data>ICA8aGludFNldExpc3Q+CiAgICA8aGludHNldCBwb2ludFRhZz0iYWIwMi
I+CiAgICAgIDxoc3RlbSBwb3M9Ii0xNCIgd2lkdGg9IjIxMSIgLz4KICAg
ICAgPGhzdGVtIHBvcz0iNDU1IiB3aWR0aD0iMTgwIiAvPgogICAgICA8aH
N0ZW0gcG9zPSI4NTYiIHdpZHRoPSIyMTEiIC8+CiAgICAgIDx2c3RlbSBw
b3M9Ijc0IiB3aWR0aD0iMzM2IiAvPgogICAgICA8dnN0ZW0gcG9zPSI4MT
kiIHdpZHRoPSIzMzYiIC8+CiAgICA8L2hpbnRzZXQ+CiAgICA8aGludHNl
dCBwb2ludFRhZz0iaHIwMiI+CiAgICAgIDxoc3RlbSBwb3M9IjIxIiB3aW
R0aD0iLTIxIiAvPgogICAgICA8aHN0ZW0gcG9zPSI0NTUiIHdpZHRoPSIx
ODAiIC8+CiAgICAgIDxoc3RlbSBwb3M9IjczOSIgd2lkdGg9IjMyOCIgLz
4KICAgICAgPHZzdGVtIHBvcz0iNzQiIHdpZHRoPSIzMzYiIC8+CiAgICAg
IDx2c3RlbSBwb3M9Ijg1MCIgd2lkdGg9IjMwNSIgLz4KICAgIDwvaGludH
NldD4KICA8L2hpbnRTZXRMaXN0Pgo=
</data>
</dict>
</lib>
<lib>
<dict>
<key>com.adobe.type.v2.autohint</key>
<dict>
<key>hintSetList</key>
<array>
<dict>
<key>element</key>
<string>hintset</string>
<key>pointTag</key>
<string>ab02</string>
<key>elements</key>
<array>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>-14</integer>
<key>width</key>
<integer>211</integer>
</dict>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>455</integer>
<key>width</key>
<integer>180</integer>
</dict>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>856</integer>
<key>width</key>
<integer>211</integer>
</dict>
<dict>
<key>element</key>
<string>vstem</string>
<key>pos</key>
<integer>74</integer>
<key>width</key>
<integer>336</integer>
</dict>
<dict>
<key>element</key>
<string>vstem</string>
<key>pos</key>
<integer>819</integer>
<key>width</key>
<integer>336</integer>
</dict>
</array>
</dict>
<dict>
<key>element</key>
<string>hintset</string>
<key>pointTag</key>
<string>hr02</string>
<key>elements</key>
<array>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>21</integer>
<key>width</key>
<integer>-21</integer>
</dict>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>455</integer>
<key>width</key>
<integer>180</integer>
</dict>
<dict>
<key>element</key>
<string>hstem</string>
<key>pos</key>
<integer>739</integer>
<key>width</key>
<integer>328</integer>
</dict>
<dict>
<key>element</key>
<string>vstem</string>
<key>pos</key>
<integer>74</integer>
<key>width</key>
<integer>336</integer>
</dict>
<dict>
<key>element</key>
<string>vstem</string>
<key>pos</key>
<integer>850</integer>
<key>width</key>
<integer>305</integer>
</dict>
</array>
</dict>
</array>
</dict>
</dict>
</array>
</dict>
</array>
</dict>
</lib>
Is that correct?
A.
Lasse Fister
Dec 9, 2014, 9:52:34 AM12/9/14
to ufo-...@googlegroups.com
On 12/09/2014 03:09 PM, Adam Twardoch (List) wrote:
> Sure, that's a possibility. But I think that's as much a dirty hack as base64.
Of course it's a hack! But it is very good human readable and it's even
> Sure, that's a possibility. But I think that's as much a dirty hack as base64.
less bloated than adobes and yours
custom-xml-inside-of-the-data-element(-as-base64)-hack.
> It requires people to learn a yet another dialect.
Yes, anything you add to data must be learned, your custom xml markup or
yaml. But it's still human readable, and that's the point for it and
against base64.
> It's like mixing Markdown, Textile, MathML and HTML in one document...
A very common practice in web development, we mix all kind of things
inside HTML all the time.
Also, mentioning MathML and HTML reminds me of your proposal of
introducing XML-Namespaces. Because that's the way how MathML can be
mixed in at least XHTML. I like the idea of using XML-Namespaces, by the
way. Though, I would use them all over the place, not just in <lib>.
Also, ufoLib would have to learn better XML parsing and the people would
have to learn working/coding with XMLNamespaces.
> You completely lose structural integrity, any correspondence between the identifiers used in the core GLIF section and the stuff in the lib -- and that's the whole point of the exercise.
I can't follow that reasoning. There simply is no correspondence between
these things. It all happens in your software, working the deserialized
data and most probably on the initialized object model. There is nothing
that makes your custom format, a base64 serialization yaml or even plist
more structural integer. Again, maybe with XML-Namespaces you could
solve some issues like this.
> I wouldn't mind to have a completely new format which could be YAML, it could even be just a full functional translation of UFO.
serialization target/alternative to ufoLib, your best bet right now
would be to serialize your data using the plist format. Because that
would be the only way how in the end glif-as-yaml could understand what
you want to do.
> But I wouldn't want to mix.
Pure plist is the best solution at the moment.
Earlier in this thread :
> 4. The base64-encoded representation of the GLIF lib data is ugly, non-readable and kind of defeats lots of purposes of UFO. It's tedious to work with.
yaml solves this
Ben Kiel
Dec 9, 2014, 9:57:36 AM12/9/14
to ufo-...@googlegroups.com
Adam,
With the major caveat that I’ve not looking at this in depth, but having looked at Tal’s email that he referenced early, is it possible that instead of using the advantages of the plist format (which at first read is how Tal sketched things out in the discussions of the Adobe hint format), the examples you are giving are trying too hard to shoehorn XML into plist?
In other words, perhaps it’s better to take a step back and see how to represent the data in the format, rather than try to represent the data in a format in a format.
Best,
Ben
With the major caveat that I’ve not looking at this in depth, but having looked at Tal’s email that he referenced early, is it possible that instead of using the advantages of the plist format (which at first read is how Tal sketched things out in the discussions of the Adobe hint format), the examples you are giving are trying too hard to shoehorn XML into plist?
In other words, perhaps it’s better to take a step back and see how to represent the data in the format, rather than try to represent the data in a format in a format.
Best,
Ben
Adam Twardoch (List)
Dec 9, 2014, 10:14:16 AM12/9/14
to ufo-...@googlegroups.com
Ben,
I guess someone who'd know PlistML better than me (which is easy) would probably shave off 3-4 lines off my examples, but not much.
I'm not trying to ridicule anything but actually trying to draft actual representation in a format that has (by design) very limited vocabulary.
The DTD of PlistML is this: http://www.apple.com/DTDs/PropertyList-1.0.dtd
It's amazingly simple. But this really is equivalent to having an alphabet with only 6 letters. If you have an alphabet that only has 6 letters, your texts are automatically much longer. The more symbols you use, the shorter the texts (compare Chinese vs. English). Also, the fact that the syntax of PlistML is very simple, it's as if no punctuation is allowed. XML dialects with more vocabulary and the ability to use attributes are like human languages which have flexible syntax, extensive punctuation and a sufficient number of symbols. PlistML is very minimalist in all these aspects so it automatically becomes much more verbose.
That said, Tal could probably cook up a slightly better representation, but I'd be surprised if it was significantly different from my examples.
Best,
Adam
I guess someone who'd know PlistML better than me (which is easy) would probably shave off 3-4 lines off my examples, but not much.
I'm not trying to ridicule anything but actually trying to draft actual representation in a format that has (by design) very limited vocabulary.
The DTD of PlistML is this: http://www.apple.com/DTDs/PropertyList-1.0.dtd
It's amazingly simple. But this really is equivalent to having an alphabet with only 6 letters. If you have an alphabet that only has 6 letters, your texts are automatically much longer. The more symbols you use, the shorter the texts (compare Chinese vs. English). Also, the fact that the syntax of PlistML is very simple, it's as if no punctuation is allowed. XML dialects with more vocabulary and the ability to use attributes are like human languages which have flexible syntax, extensive punctuation and a sufficient number of symbols. PlistML is very minimalist in all these aspects so it automatically becomes much more verbose.
That said, Tal could probably cook up a slightly better representation, but I'd be surprised if it was significantly different from my examples.
Best,
Adam
Tal Leming
Dec 9, 2014, 10:17:10 AM12/9/14
to ufo-...@googlegroups.com
> On Dec 9, 2014, at 8:40 AM, Adam Twardoch (List) <list...@twardoch.com> wrote:
> But, generally, it's no problem to express it all in plist XML. Plist XML ist just 1 level more verbose than normal XML because for each XML element you need to make a plist dict, where you store each XML attribute as a key-value pair, enumerating the data type each time. It's about 3x larger than the normal XML and much less human-readable.
> There is no problem to express any HTML document, or the Adobe hinting structures, or the FontLab TTH structures, or, in fact, the core GLIF structure, using plist XML. In fact, if the core GLIF structure were expressed using plist XML, I would say that the lib structures also should.
> Plist XML is not real XML because it doesn't use attributes, just elements
> I see. So I guess in order to stay compliant, we'd need to urge Adobe and FontLab (i.e. ourselves) to:
> a) either always use normal XML hidden inside a base64-encoded <data> element
> b) or convert our nice normal XML structures into exploded plist XML as I've shown above
> In one section of the GLIF, the same data entity (a point name) exists as an XML attribute while in another, it exists as XML *contents*. This is apples and oranges in one.
Thanks,
Tal
Tal Leming
Dec 9, 2014, 10:27:09 AM12/9/14
to ufo-...@googlegroups.com
> On Dec 9, 2014, at 9:52 AM, Lasse Fister <newsl...@graphicore.de> wrote:
Okay, I don't want to get involved in this YAML vs HAML vs JSON vs PLIST vs XML vs WTVR debate because it's completely subjective, but I have to jump in here:
> If we would create a glif-as-yaml format and maybe add it as a
> serialization target/alternative to ufoLib
Tal
Lasse Fister
Dec 9, 2014, 10:31:44 AM12/9/14
to ufo-...@googlegroups.com
Adam, I serialized your plist as yaml just, to have the comparison.
<lib>
<dict>
<key>com.adobe.type.autohint</key>
<string>
- element: hintset
pointTag: ab02
elements:
- element: hstem
pos: -14
width: 211
- element: hstem
pos: 455
width: 180
- element: hstem
pos: 856
width: 211
- element: vstem
pos: 74
width: 336
- element: vstem
pos: 819
width: 336
- element: hintset
pointTag: hr02
elements:
- element: hstem
pos: 21
width: -21
- element: hstem
pos: 455
width: 180
- element: hstem
pos: 739
width: 328
- element: vstem
pos: 74
width: 336
- element: vstem
pos: 850
width: 305
</string>
</dict>
</lib>
<lib>
<dict>
<key>com.adobe.type.autohint</key>
- element: hintset
pointTag: ab02
elements:
- element: hstem
pos: -14
width: 211
- element: hstem
pos: 455
width: 180
- element: hstem
pos: 856
width: 211
- element: vstem
pos: 74
width: 336
- element: vstem
pos: 819
width: 336
- element: hintset
pointTag: hr02
elements:
- element: hstem
pos: 21
width: -21
- element: hstem
pos: 455
width: 180
- element: hstem
pos: 739
width: 328
- element: vstem
pos: 74
width: 336
- element: vstem
pos: 850
width: 305
</string>
</dict>
</lib>
Adam Twardoch (List)
Dec 9, 2014, 10:42:04 AM12/9/14
to ufo-...@googlegroups.com
Tal,
> I think you are missing the point. There is official and unofficial. The official part is the data that we *know* about and can specify universally—points, contours, etc. That can be expressed in nice, compact XML. We can't do that for everything because new tools are being invented all the time—relative accent positioning, N-dimensional interpolation spaces, etc. (Thanks in no small part to the flexibility of the UFO!) To support that we need a place where arbitrary data can go. That data *must* be readable and writable without knowing the data structure schema. This allows tools to losslessly read and write data structures that they have no knowledge of. That can't be (easily) done with ad-hoc XML.
That is a sound argument, thanks.
>> Plist XML is not real XML because it doesn't use attributes, just elements
>
> That doesn't make it not real XML.
Strictly speaking, no. But XML was invented as an attempt to balance between human- and machine-readable. It's not at all a good machine-only data storage format. It's a machine data storage format which also acts as a human-machine interface without causing people's heads to explode. And PlistML is, well, very heavily shifted towards the machine end. I'm not saying it's a disqualifier, it's more a point of aesthetics. The XML attributes in the traditional "prettified" (indented) XML presentational form act as an aid for the human eye to understand the data structure. Additional tools like code colorizers help even more. Just compare the examples of "real"* XML vs. PlistML I put on https://github.com/adobe-type-tools/afdko/issues/25 -- you can instantly understand what's going on in the 1st example, but not in the PlistML. You know I'm right ;)
*) by "real", I mean XML dialects that use a sensibly large subset of the features XML offers; it's just my private use of the word in this context
Still, I do value the first argument you brought above. It is a sound argument. I guess what you MAY be saying is: if you want your data structures to be "prettier", make an effort to standardize them in core UFO/GLIF. Right? :)
>> I see. So I guess in order to stay compliant, we'd need to urge Adobe and FontLab (i.e. ourselves) to:
>> a) either always use normal XML hidden inside a base64-encoded <data> element
>> b) or convert our nice normal XML structures into exploded plist XML as I've shown above
>
> I wouldn't say "stay compliant". I'd say "not mess up your users' files". ;-) The spec doesn't exist to be some arbitrary measuring device. It exists to protect users from data loss. That's why we started this whole thing.
I agree. If people want to use UFO, they should use UFO to the letter. If they don't like UFO, they should invent something better and write software to support it. Thanks! :)
>> In one section of the GLIF, the same data entity (a point name) exists as an XML attribute while in another, it exists as XML *contents*. This is apples and oranges in one.
>
> Why is this a problem? I'm not trying to be dense, I just don't see how this is a problem. A corresponds to B. It's just the representation of the data, not the data itself.
There are some (minor) technical caveats. If I want to use the double-quote in a point name, my software needs to make sure that in the name="xxx" element, it's escaped somehow (I don't even know how :) ) while in <string>xxx</string>, it should not be escaped. If people forget to do such things while authoring XML by hand, they can make mistakes.
But also, from the human point of view, working with real XML and PlistML within the same document is like when you're doing taxes, and the invoices from 2012 are sorted chronologically while the invoices from 2013 are sorted alphabetically by the issuer's name. It's a burden.
For the machine, it surely doesn't matter.
The "UFO Design Philosophy" states:
1. The data must be human readable and human editable.
2. The data should be application independent.
3. Data duplication should be avoided unless absolutely necessary.
PlistML makes the point 1 a bit shaky.
Again, I do agree with your first argument, so I won't go anymore philosophical on this (because I think we've exhausted it).
After discussions with Yuri, we've concluded that in FontLab apps, the current Adobe representation for PostScript hints and the FontLab representation for visual TrueType hints will use the currently-defined custom XML but will be base64 encoded as a recommended storage form. There will be a way to store it in raw form but only as a "debug" method, and it will not be recommended. I'd call this "UFO 2" level.
For UFO 3, I'll make an effort to convince both FontLab and Adobe to switch the representation to a new, compliant format. Rather than re-engineering its logical structure, I'll recommend to both parties that we apply the "real XML-to-PlistML" expansion method of which I have given examples here.
Many thanks,
Adam
> I think you are missing the point. There is official and unofficial. The official part is the data that we *know* about and can specify universally—points, contours, etc. That can be expressed in nice, compact XML. We can't do that for everything because new tools are being invented all the time—relative accent positioning, N-dimensional interpolation spaces, etc. (Thanks in no small part to the flexibility of the UFO!) To support that we need a place where arbitrary data can go. That data *must* be readable and writable without knowing the data structure schema. This allows tools to losslessly read and write data structures that they have no knowledge of. That can't be (easily) done with ad-hoc XML.
>> Plist XML is not real XML because it doesn't use attributes, just elements
>
> That doesn't make it not real XML.
*) by "real", I mean XML dialects that use a sensibly large subset of the features XML offers; it's just my private use of the word in this context
Still, I do value the first argument you brought above. It is a sound argument. I guess what you MAY be saying is: if you want your data structures to be "prettier", make an effort to standardize them in core UFO/GLIF. Right? :)
>> I see. So I guess in order to stay compliant, we'd need to urge Adobe and FontLab (i.e. ourselves) to:
>> a) either always use normal XML hidden inside a base64-encoded <data> element
>> b) or convert our nice normal XML structures into exploded plist XML as I've shown above
>
> I wouldn't say "stay compliant". I'd say "not mess up your users' files". ;-) The spec doesn't exist to be some arbitrary measuring device. It exists to protect users from data loss. That's why we started this whole thing.
>> In one section of the GLIF, the same data entity (a point name) exists as an XML attribute while in another, it exists as XML *contents*. This is apples and oranges in one.
>
> Why is this a problem? I'm not trying to be dense, I just don't see how this is a problem. A corresponds to B. It's just the representation of the data, not the data itself.
But also, from the human point of view, working with real XML and PlistML within the same document is like when you're doing taxes, and the invoices from 2012 are sorted chronologically while the invoices from 2013 are sorted alphabetically by the issuer's name. It's a burden.
For the machine, it surely doesn't matter.
The "UFO Design Philosophy" states:
1. The data must be human readable and human editable.
2. The data should be application independent.
3. Data duplication should be avoided unless absolutely necessary.
PlistML makes the point 1 a bit shaky.
Again, I do agree with your first argument, so I won't go anymore philosophical on this (because I think we've exhausted it).
After discussions with Yuri, we've concluded that in FontLab apps, the current Adobe representation for PostScript hints and the FontLab representation for visual TrueType hints will use the currently-defined custom XML but will be base64 encoded as a recommended storage form. There will be a way to store it in raw form but only as a "debug" method, and it will not be recommended. I'd call this "UFO 2" level.
For UFO 3, I'll make an effort to convince both FontLab and Adobe to switch the representation to a new, compliant format. Rather than re-engineering its logical structure, I'll recommend to both parties that we apply the "real XML-to-PlistML" expansion method of which I have given examples here.
Many thanks,
Adam
Adam Twardoch (List)
Dec 9, 2014, 10:47:18 AM12/9/14
to ufo-...@googlegroups.com
Tal,
you say:
>> If we would create a glif-as-yaml format and maybe add it as a
>> serialization target/alternative to ufoLib
>
> This is nuts. Completely changing the data format of GLIF is a very, very, very bad idea.
We have TTX and we have TTF -- one is an XML representation and one is the binary representation of the same data. I don't see why we can't have UFO/GLIF as an XML representation and YUFO/YGLIF as a YAML representation, or something.
I'm no expert at all on the YAML / HAML / JSON storage forms but I can see a benefit of having a less verbose storage variant, as long as we have software to move between the two.
Best,
Adam
you say:
>> If we would create a glif-as-yaml format and maybe add it as a
>> serialization target/alternative to ufoLib
>
> This is nuts. Completely changing the data format of GLIF is a very, very, very bad idea.
and yet before, you said:
> Why is this a problem? I'm not trying to be dense, I just don't see how this is a problem. A corresponds to B. It's just the representation of the data, not the data itself.
I don't see a problem in offering an alternative serialization model as long as the data remains structurally the same.
> Why is this a problem? I'm not trying to be dense, I just don't see how this is a problem. A corresponds to B. It's just the representation of the data, not the data itself.
We have TTX and we have TTF -- one is an XML representation and one is the binary representation of the same data. I don't see why we can't have UFO/GLIF as an XML representation and YUFO/YGLIF as a YAML representation, or something.
I'm no expert at all on the YAML / HAML / JSON storage forms but I can see a benefit of having a less verbose storage variant, as long as we have software to move between the two.
Best,
Adam
Grzegorz Rolek
Dec 9, 2014, 10:50:05 AM12/9/14
to ufo-...@googlegroups.com
On 09 Dec 2014, at 16:17, Tal Leming <t...@typesupply.com> wrote:
> That data *must* be readable and writable without knowing the data structure schema. This allows tools to losslessly read and write data structures that they have no knowledge of. That can't be (easily) done with ad-hoc XML.
Nonetheless, I think that the XML side of UFO is a bit underused in terms of the whole family of XML technologies. Namespaces are an obvious example, but also think about XPath and the various ways it could be used to cross-reference pieces of data between all the various sub-domains, instead of plain name reference or whatever, as it is done today.
Regards,
Grzegorz Rolek
Adam Twardoch (List)
Dec 9, 2014, 10:52:40 AM12/9/14
to ufo-...@googlegroups.com
> Nonetheless, I think that the XML side of UFO is a bit underused in terms of the whole family of XML technologies. Namespaces are an obvious example, but also think about XPath and the various ways it could be used to cross-reference pieces of data between all the various sub-domains, instead of plain name reference or whatever, as it is done today.
APAGE SATANAS!!!
:)
A.
Tal Leming
Dec 9, 2014, 11:03:25 AM12/9/14
to ufo-...@googlegroups.com
Okay, here goes. First thing, don't try to handwrite PLIST. You'll go crazy and get so mad that you post a whole bunch of emails to mailing lists complaining about PLIST. I *always* sketch it out with this representation:
{} = key value dictionary
[] = array
"" = string
# = comment
| = delimiter between options
This is my internal structure for representing the same data that is in "com.fontlab.v2.tth". My version is much more verbose because I like keys and values that are very clear. It also stores more data than "com.fontlab.v2.tth". Anyway:
> {
> instructions : [
> # an array of instructions defined as dictionaries.
> # see below for the definitions.
> ]
> }
>
> # Instruction Dictionaries
>
> {
> type : "align horizontal"
> point : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> }
>
> {
> type : "single link horizontal"
> point : "point name"
> linkedPoint : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> stem : "stem name"
> }
>
> {
> type : "double link horizontal"
> point : "point name"
> linkedPoint : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> stem : "stem name"
> }
>
> {
> type : "interpolate horizontal"
> point : "point name"
> basePoint1 : "point name"
> basePoint2 : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> }
>
> {
> type : "middle delta horizontal"
> point : "point name"
> distance : int
> size1 : int
> size2 : int
> }
>
> {
> type : "align bottom"
> point : "point name"
> zone : "zone name"
> }
>
> {
> type : "align top"
> point : "point name"
> zone : "zone name"
> }
>
> {
> type : "align vertical"
> point : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> }
>
> {
> type : "single link vertical"
> point : "point name"
> linkedPoint : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> stem : "stem name"
> }
>
> {
> type : "double link vertical"
> point : "point name"
> linkedPoint : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> stem : "stem name"
> }
>
> {
> type : "interpolate vertical"
> point : "point name"
> basePoint1 : "point name"
> basePoint2 : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> }
>
> {
> type : "middle delta vertical"
> point : "point name"
> distance : int
> size1 : int
> size2 : int
> }
>
> {
> type : "final delta vertical"
> point : "point name"
> distance : int
> size1 : int
> size2 : int
> }
As for what the PLIST XML looks like, I have no idea. I'm much more concerned with the data representing things in an organized, logical way that I can interact with easily. The data structure above does that quite nicely.
Thanks,
Tal
{} = key value dictionary
[] = array
"" = string
# = comment
| = delimiter between options
This is my internal structure for representing the same data that is in "com.fontlab.v2.tth". My version is much more verbose because I like keys and values that are very clear. It also stores more data than "com.fontlab.v2.tth". Anyway:
> {
> instructions : [
> # an array of instructions defined as dictionaries.
> # see below for the definitions.
> ]
> }
>
> # Instruction Dictionaries
>
> {
> type : "align horizontal"
> point : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> }
>
> {
> type : "single link horizontal"
> point : "point name"
> linkedPoint : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> stem : "stem name"
> }
>
> {
> type : "double link horizontal"
> point : "point name"
> linkedPoint : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> stem : "stem name"
> }
>
> {
> type : "interpolate horizontal"
> point : "point name"
> basePoint1 : "point name"
> basePoint2 : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> }
>
> {
> type : "middle delta horizontal"
> point : "point name"
> distance : int
> size1 : int
> size2 : int
> }
>
> {
> type : "align bottom"
> point : "point name"
> zone : "zone name"
> }
>
> {
> type : "align top"
> point : "point name"
> zone : "zone name"
> }
>
> {
> type : "align vertical"
> point : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> }
>
> {
> type : "single link vertical"
> point : "point name"
> linkedPoint : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> stem : "stem name"
> }
>
> {
> type : "double link vertical"
> point : "point name"
> linkedPoint : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> stem : "stem name"
> }
>
> {
> type : "interpolate vertical"
> point : "point name"
> basePoint1 : "point name"
> basePoint2 : "point name"
> alignmentType : "none | closest | left/bottom | right/top | center | double grid"
> }
>
> {
> type : "middle delta vertical"
> point : "point name"
> distance : int
> size1 : int
> size2 : int
> }
>
> {
> type : "final delta vertical"
> point : "point name"
> distance : int
> size1 : int
> size2 : int
> }
As for what the PLIST XML looks like, I have no idea. I'm much more concerned with the data representing things in an organized, logical way that I can interact with easily. The data structure above does that quite nicely.
Thanks,
Tal
Tal Leming
Dec 9, 2014, 11:20:06 AM12/9/14
to ufo-...@googlegroups.com
> On Dec 9, 2014, at 10:42 AM, Adam Twardoch (List) <list...@twardoch.com> wrote:
>
> Still, I do value the first argument you brought above. It is a sound argument. I guess what you MAY be saying is: if you want your data structures to be "prettier", make an effort to standardize them in core UFO/GLIF. Right? :)
1. The low hanging-fruit has been picked. Contours, points, kerning and all of that stuff is not up to much interpretation and we've had 10+ years of figuring out how to standardize it. The more complex things like high-level representations of hinting data are vastly different from tool to tool. Figuring out what needs to be stored officially or unofficially is hard enough. How to store it is another level of complexity.
2. The rate of invention right now is incredibly fast. We're seeing new things enter the R&D phase in some tools — multi-style relationships, parametric design, and so on. We can't rush to standardize these things because they aren't commonly used let alone commonly implemented. We're very careful about putting things that suddenly appear into the spec (remember when there was a big push to put Spiro curves in GLIF?). Our job is to try to figure out what is sticking, find the base data structure of it and build a way for very opinionated tool developers communicate with each other politely through the data. We can't be too early and we can't drive it. (This is why the lib is so important!)
These are VERY good problems to have. It means that our toolsets are growing and the techniques that are used to practice our craft are growing. I've been hacking away at font tools since before it was cool, but I am in awe every day of the new stuff that is coming. We're all going through growing pains right now. It's a good thing!
Thanks,
Tal
Tal Leming
Dec 9, 2014, 11:24:34 AM12/9/14
to ufo-...@googlegroups.com
> On Dec 9, 2014, at 10:47 AM, Adam Twardoch (List) <list...@twardoch.com> wrote:
>
> I don't see why we can't have UFO/GLIF as an XML representation and YUFO/YGLIF as a YAML representation, or something.
UFO 3 was a big change and it didn't even introduce a new data format. Implementing that, even in my own tools, is taking a long time. I don't want to think about what would happen if we had two parallel but completely different syntaxes. I think our limited time would be much better spent building a robust test suite than going through the spec and defining a bunch of alternatives and exceptions.
Thanks,
Tal
Adam Twardoch (Lists)
Dec 9, 2014, 11:59:39 AM12/9/14
to ufo-...@googlegroups.com
Ben,
I guess someone who'd know PlistML better than me (which is easy) would probably shave off 3-4 lines off my examples, but not much.
I'm not trying to ridicule anything but actually trying to draft actual representation in a format that has (by design) very limited vocabulary.
The DTD of PlistML is this: http://www.apple.com/DTDs/PropertyList-1.0.dtd
It's amazingly simple. But this really is equivalent to having an alphabet with only 6 letters. If you have an alphabet that only has 6 letters, your texts are automatically much longer. The more symbols you use, the shorter the texts (compare Chinese vs. English). Also, the fact that the syntax of PlistML is very simple, it's as if no punctuation is allowed. XML dialects with more vocabulary and the ability to use attributes are like human languages which have flexible syntax, extensive punctuation and a sufficient number of symbols. PlistML is very minimalist in all these aspects so it automatically becomes much more verbose.
That said, Tal could probably cook up a slightly
Best,
Adam
On 09 Dec 2014, at 15:57, Ben Kiel <b...@benkiel.com> wrote:
Reply all
Reply to author
Forward
0 new messages