Upgrading from plist format

[Dave Crossland]

Hi!

Here is a (rather snooty) comment regarding the use of plist in UFO:

/* A little comment about the ufo data-directory format (it isn't really a
* file format; but using the file system directly for the structure of a
* composite media object is a lot better than what most applications do).
*
* The painful part is the use of XML plists. The desire to do something clean
* for adding user data has wasted too many hours; the amount of code it would
* take to do something this trivial has prevented me from properly starting
* adding the feature. Even with a SAX like parser at my disposal the format
* is ugly and unapproachable; not willing to change this until UFO changes
* the .plists for something with less technical cost/debt.
*
* I suspect other .plist dealing code in kernagic has a bug^Wmalfeature -
* that likely is masked by painlist parsers; as long as it works those .plist
* files are no less broken than the format already is.
*/
- https://github.com/hodefoting/kernagic/blob/master/lib-plist.c#L26

I wonder if UFOv4 might replace the plist files with a better format? :-)

--
Cheers
Dave

[Erik van Blokland]

On 29 okt. 2013, at 23:14, Dave Crossland <da...@lab6.com> wrote:

- https://github.com/hodefoting/kernagic/blob/master/lib-plist.c#L26

I wonder if UFOv4 might replace the plist files with a better format? :-)

Python has a plist reader/writer in the standard library. Surely that means it is implementable in C?

Erik

[Tal Leming]

I found a C implementation:

http://www.opensource.apple.com/source/BootX/BootX-81/bootx.tproj/sl.subproj/plist.c

As for switching from property lists: we have backwards compatibility concerns so this isn't likely to change. The other options are another serialized format or arbitrarily defined formats specific to each file. The former would have the same issues as property lists and the latter would require a different parser for each file type in the UFO. Everything has its drawbacks, the grass is always greener in JSON, etc.

Tal

--
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/groups/opt_out.

[Dave Crossland]

On 29 October 2013 19:01, Tal Leming <t...@typesupply.com> wrote:
> we have backwards compatibility concerns

I'm curious why a v4 would have any backwards compatibility concerns?

[Tal Leming]

Because I don't think it is wise to tell developers that they have to completely throw out their existing support and start over. UFO3 was a big change but still based on UFO2 which was in turn based on UFO1.

Tal

[Dave Crossland]

On 29 October 2013 19:27, Tal Leming <t...@typesupply.com> wrote:
> Because I don't think it is wise to tell developers that they have
> to completely throw out their existing support and start over.
> UFO3 was a big change but still based on UFO2 which was in turn based on UFO1.

I suggest throwing out plist support for eg yaml would not be a
'complete' overhaul.

.plists do not encode floating point numbers, only integers. This
makes them very limited as a format for storing arbitrary data.

The plist.c you mentioned isn't useful for adding/modifying a specific
key in-place.

[Tal Leming]

> On Oct 29, 2013, at 7:30 PM, Dave Crossland <da...@lab6.com> wrote:
>
> I suggest throwing out plist support for eg yaml would not be a
> 'complete' overhaul.

It's a format change that requires a new parser for a large portion of the UFO format for existing implementations. That is not a trivial change. Beyond "some people don't like plist", how are property lists not working in the UFO right now? That isn't clear to me.

> .plists do not encode floating point numbers, only integers.

That is not true.

> The plist.c you mentioned isn't useful for adding/modifying a specific
> key in-place.

So change it or find another? It's open source...

Tal

[Ben Kiel]

> .plists do not encode floating point numbers, only integers. This
> makes them very limited as a format for storing arbitrary data.

Last time I checked the spec, both integers and real numbers are supported. Where do you see that this isn't the case?

[rrob...@adobe.com]

Hi David;

The point about support is that tools which support UFO 3 but not UFO 4 ( which is all of them, at this point), wouldn't work with UFO 4 fonts, if the current format were changed that drastically. The expectation in the UFO environment is that a higher version number is used only as a flag to look for additional data, and does not mean that older tools cannot use the new format. I suspect that this is why the plist format was used - the designers expected the content to change a lot over time, and wanted to be able to add any data anywhere, without breaking support in tools. Given how much the format has evolved, I think this was a good idea. 

If I understand correctly, the complaint is just that there is not already a good plist parser in C that lets you easily update any node. This shouldn't be that hard - I would guess three to five man days, if written from scratch, that would read/write a tree of nodes in memory.  I do agree that a YAML text file is much easier to read and is more efficient in file size than a plist format file, where over half the file can be the XML element tags. However, we are way past the days of worrying about file size, and the plist format doesn't look to me as if is is significantly harder to parse  in C than the YAML format. 

- Read

[Yuri Yarmola]

While in general I am OK with using .plist, there is one place where it is just not really nice. 

It is lib.plist where I am supposed to put some font-level data.

It will be very nice location to store "global" data for "visual" tt instructions and I certainly would like to make this data easily readable, stored in XML format.

Something that .plist doesn't allow me to do for formal reasons.

Using simple XML for that (with some restrictions and recommendations) similar to <lib> part of .glif, will be much better.

Currently I have no good option to store data in UFO2 (other than packing XML into base64) and will have to put it into data folder in UFO3 which is a bit strange for plain XML format.

Best regards,

Yuri

[rrob...@adobe.com]

Hi Yuri;

One hack is to embed the XMLas a CDATA section element.  I had to do this when embedding SVG docs in XML for ttx, since XML parses won't allow the initial xml declaration of an SVG anywhere except at the start of a file. Example:

<![CDATA[

character data other than the CDATA close sequence

    ]]>

[Yuri Yarmola]

Hi Read,

Well, as an intermediate solution I can just try to convert XML data into .plist dict/arrays. It is not something that I'd like to do, but at least it will work without hacks :)

So instead of just storing something like 

      <zone location="bottom" position="0" width="39" name="b: 0">

        <delta ppm="24" value="8"/>

        <delta ppm="26" value="8"/>

        <delta ppm="30" value="8"/>

      </zone>

it will be 

<key>b: 0</key>

<dict>

  <key>position</key>

  <integer>0</integer>

  <key>width</key>

  <integer>39</integer>

  <key>top</key>

  <false/>

  <key>delta</key>

  <dict>

    <key>24</key>

    <integer>8</integer>

    <key>26</key>

    <integer>8</integer>

    <key>30</key>

    <integer>8</integer>

  </dict>

</dict>

Can't say that it will make me happy, but OK :)

Yuri

пятница, 22 ноября 2013 г., 20:47:09 UTC+4 пользователь rrob...@adobe.com написал:

[Tal Leming]

Hi Yuri,

Yeah, the XML in Property Lists is not the prettiest thing but it’s not a terrible tradeoff considering what they make possible. When I am working out a data structure I find it easier to look at them as pretty printed versions of the objects they represent. For example, this is how I would look at your example:

b: 0 : {
position : 0,
width : 39,
top : False,
delta : {
24 : 8,
26 : 8,
30 : 8
}
}

Much nicer than <key>…</key><dict><key>…</key><integer>…</integer></dict> :-)

Tal

[Dave Crossland]

On 25 November 2013 09:57, Tal Leming <t...@typesupply.com> wrote:
>
> Yeah, the XML in Property Lists is not the prettiest thing but
> it's not a terrible tradeoff considering what they make possible.
> When I am working out a data structure I find it easier to look
> at them as pretty printed versions of the objects they represent.

Would a preprocessor help, similar to Markdown/reStructuredText?

[Tal Leming]

I’m very familiar with Md/reST, but I don’t know what you mean with regards to Property Lists. Could you elaborate?

Tal

[Dave Crossland]

On 25 November 2013 13:41, Tal Leming <t...@typesupply.com> wrote:
> I’m very familiar with Md/reST, but I don’t know what you
> mean with regards to Property Lists. Could you elaborate?

From the thoughtful discussion on this thread I conclude that plists
are useful, somewhat for legacy reasons (which are not invalid) - but
inelegant - much like HTML.

So I wonder about using a yaml representation in the lib directory
that is compiled into plist format, similar to the way writing is
stored in markdown and used in html compiled into html for use.

[Tal Leming]

Aha. Well, lib isn’t a directory. It’s a Property List so one would have to store a preprocessed plist inside of a processed plist. :-) It would also violate the “no duplicate data” design rule.

Tal

[Dave Crossland]

On 25 November 2013 14:08, Tal Leming <t...@typesupply.com> wrote:
> Aha. Well, lib isn’t a directory. It’s a Property List so one would have to store a preprocessed plist inside of a processed plist. :-)

Oops - I meant http://unifiedfontobject.org/versions/ufo3/data.html :)

> It would also violate the “no duplicate data” design rule.

How do you feel about duplication with deprecation for backwards
compatibility? :)

[Tal Leming]

On Nov 25, 2013, at 2:27 PM, Dave Crossland <da...@lab6.com> wrote:

> On 25 November 2013 14:08, Tal Leming <t...@typesupply.com> wrote:
>> Aha. Well, lib isn’t a directory. It’s a Property List so one would have to store a preprocessed plist inside of a processed plist. :-)
>
> Oops - I meant http://unifiedfontobject.org/versions/ufo3/data.html :)

Sure, someone can put a preprocessed version there under org.plisthaters.preprocessed.font.lib, org.plisthaters.preprocessed.all.the.other.libs, etc. (have fun figuring how to handle glyph.lib :-) but it’s not going to be an official part of the spec and they should not expect *everyone* else to read the lib from there.

>> It would also violate the “no duplicate data” design rule.
>
> How do you feel about duplication with deprecation for backwards
> compatibility? :)

We’re still at the “Why? Um…because I don’t like it.” stage so I don’t think it’s prudent to start planning an exit strategy now.

Tal

[Yuri Yarmola]

Hi Tal,

Well, I am not on Python and for C++ plain XML is a bit more natural :)

Yuri

понедельник, 25 ноября 2013 г., 18:57:23 UTC+4 пользователь Tal Leming написал: