Dropbox, UFO, and .dmg

[Mark Simonson]

I’ve basically given up trying to use Dropbox to sync UFOs between machines. Dropbox is just not optimized to handle synchronizing the masses of tiny files that reside inside a UFO very well. On several occassions I had to wait days for Dropbox to finish syncing due to simple things like changing a directory name or moving a directory.

But it occurred to me that it might work to put the UFOs into a disk image (.dmg) in my Dropbox directory. Seems like it should work, and I’m going to try it, but I wondered if anyone else has tried this already.

Mark

[Dave Crossland]

You might have more luck with sparkle share and git :)

--
--
You received this message because you are subscribed to the Google Groups "RoboFab" group.
To post to this group, send email to rob...@googlegroups.com
To unsubscribe from this group, send email to robofab-u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/robofab?hl=en

Messages from newly joined members are subject to moderation.
Download RoboFab and documentation at http://robofab.com
---
You received this message because you are subscribed to the Google Groups "RoboFab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robofab+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nick Sherman]

That's an interesting idea, but I can't say I've tried it.

Another option would be using a code repository instead of Dropbox (which allows for other potential benefits as well).

Otherwise, maybe we can get Just van Rossum to put in a good word for better UFO handling with his brother Guido, who is now working at Dropbox.

N

[Erik van Blokland]

I exchanged some emails with a dropbox person about UFO support. It went roughly like so "how many people are using UFO?" "fewer than a million? Good luck! HAHAHAHA".



Erik

[David Březina]

Sorry for the sidetrack. I do not think git is a solution here. I see the problem on the UFO side of things. UFOs actually being thousands of little files. I appreciate the conceptual beauty in it being textual source and all that, but I do not understand the utility of file-per-glyph in the context of git and, well, type design. It simply bloats the whole system (manageability as well as file size). Type design is full of global changes and file-per-glyph system becomes difficult to manage. What I mean is that tracking and commits of thousands of files is certainly more difficult than, say, tracking a couple of files with master fonts or even one MM. I know that git is for managing code, but is it still useful if with one global change, thousands of code changes are produced? Am I the only one seeing this as a problem?

Perhaps, the FontLab’s zipped UFOs is an answer? Perhaps, there is a very simple way how to set things up with git or UFO which I am missing.

David

[Martin Wenzel]

How about using Cubby, would that be an alternative?
I have not yet had problems with cubby and UFO (though I haven’t properly tested it).

Best,
Martin

[Roberto Arista]

Hi everybody!

I usually share ufos through Dropbox, this is my workaround:

1. block syncing

2. work on ufos

3. launch this script

https://gist.github.com/roberto-arista/a2607a892254a71f159f

This script looks for all the ‘folders’ ending in ‘.ufo’ inside a given path, it compresses them and deletes the original ufos

4. active syncing

Basically I only share zip files. Everyone who shares the Dropbox folder has to decompress archives with blocked syncing or outside.

I hope this could be useful.

Kind regards

–––

Roberto Arista
http://robertoarista.it
–––

Mobile BE: +32 494 71 38 56
Mobile IT: +39 366 4537413
Skype: jimbo475
–––
My public PGP key is here:
http://projects.robertoarista.it/robertoArista_publicKey.txt

–––

[Tal Leming]

FWIW, I don't have an immediate solution to this, but it is definitely on my radar as the spec editor. I'll be talking about it at Robothon.

Tal

[Dave Crossland]

SparkleShare turns git into a dropbox-like no hassle solution

[Tal Leming]

I don't want to get into this too deeply, because then I'll have to start over on my Robothon presentation. But, this is a good point and it's worth addressing lightly for now.

The UFO is what is called a package and packages are a well established file structure. Back when the UFO was invented 10+ years ago, this was a really good solution for our needs. It's still a good solution for what we have been using it for, but times and technologies change. Dropbox (and other off-site storage solutions) use various protocols and techniques for moving files around. It happens that the way that Dropbox works is better at moving a few large files than lots of tiny files. That makes perfect sense for what they are doing as most of their users are going to be storing large files (photos, videos, etc.) and relatively few smaller files (Word, PDF, etc.). It's good for them, but it sucks for type designers. Everything can't be perfect for everything. So, I'm starting to wonder if the UFO spec needs to adapt rather than hoping that technology and network protocols will solve the problem. Zips are one possible solution (no joke: I experimented with a zipped version of UFO shortly after we put the first UFO 1 documentation on the old LettError wiki, the code may even be deep in the RoboFab CVS/SVN/Git archive), but they are not a perfect solution for a variety of reasons. They are absolutely terrible, maybe unusably so, in a few ways. There are other ways to address the problem, but they have different issues than Zip. We as a community are going to have to have a discussion about what we need and what we can live with.

So, yeah, we can talk about this at Robothon and then on the UFO spec mailing list after that. It's a very good thing to talk about.

Tal

[Frank Grießhammer]

David, I have to politely disagree with you here.

Once you get used to it, git is a very handy solution to this problem. 

I now immediately set up all my projects (at work and at home) as git repositories; and more often than not this has been more beneficial than problematic. For instance, in Robofont it is simple to just accidentally delete a glyph without noticing it (as happened yesterday); git tells me exactly what happened. 

Git also forces me to “document” steps in my work via commit messages and describe them, which I think is a good thing. 

Robofont has gotten much better at not writing random data into .glif files; so it is nice to see which files a.k.a.  glyphs have actually changed since the latest commit – I really would not want to go back to a big, binary MMVFB. 

The benefits really outweigh the issues here. 

As I am sure you know (but not everybody reading this might): Git repos can be stored on hosting services such as Github ($$ if you want private repos) and Bitbucket (free for personal, private repos).

I don't disagree that I/O speed is a problem with UFO. Opening a huge font is still much faster in FL; but I am glad to trade the binary “black box” for slower read/write speeds. 

Maybe there could be something like a binary UFO format for speed-critical operations; and a documented conversion utility? (of course, the conversion would need to go both ways, and is a bit risky — who doesn’t love a corrupted VFB). 

I am glad this is being discussed, see this just as my endorsement for Git in a type design workflow. 

BTW – In the end, Git ends up being a collection of thousands of tiny files. Millions of people use it. I wonder how that performs with Dropbox. 

Looking forward to Robothon!

See you there!

Frank

from a two-dimensional keyboard

[Adam Twardoch (List)]

Hello Tal,

It's excellent that you're working on something in this direction. Perhaps you'll find a few comments useful:

1. You state correctly that "The UFO is what is called a package and packages are a well established file structure" — however, you omit the key portion of the sentence. Packages are a well-established file structure on Apple operating systems (Mac OS X and iOS). They are virtually unknown to other operating systems (Windows, Linux/Unix), which makes them a far-from-universal solution. The Apple packages are a great invention, and I personally love them — but they're tied to one particular vendor.

2. When you say that ZIP is "absolutely terrible", then I trust your judgement. But I must add that it's in good company: PDF, OTF, HTML, VFB and UFO are all "absolutely terrible" in some ways, and good in others.

3. I'm not an expert of file storage systems. However, I cannot help but notice that a ZIP-based container that stores multiple files has found extremely wide adoption in the software industry as a document storage format. The e-Book EPUB format (.epub) [2], the Microsoft Office 2007 and later formats (.docx, .xslx, .pptx) [3], the Open Document Format (ODF) used by OpenOffice and LibreOffice (.odt, .ods, .odp) [4], the Adobe Acrobat PDF Portfolio format [5], and the Apple iWork format for versions 09 and earlier (.pages. .numbers, .key) *all* use a ZIP-based multiple-file container. Some of these container formats (most notably EPUB, Microsoft Office and ODF) are international standards and are well-specified. Some of them restrict the feature set of the ZIP format to a stricter subset, some even disable ZIP compression, but "going the ZIP way" seems to be their preferred choice.

4. Apple’s iWork was a curious case: until iWork 09, Apple used a dual method for storing their documents: a .key or .pages document could either be an Apple package (i.e. a folder with the extension .key or .pages) or a ZIP archive (i.e. a file with the extension .key or .pages), and the iWork apps treated them fully transparently. When iWork was ported to iOS, Apple changed the file formats, and currently it’s a hybrid (a package containing ZIPs) [6].

I'm looking forward to your talk. I would be keen to hear what exactly makes ZIP an "absolutely terrible" choice. Perhaps you might even choose to share why you think so despite the fact that Adobe, Apache, Apple, Microsoft and other major vendors widely chose a ZIP-based container as their storage format, and some even went through the process of international standardization.

Best,
Adam


[1] Wikipedia: Package (OS X)
http://en.wikipedia.org/wiki/Package_%28OS_X%29

[2] International Digital Publishing Forum: EPUB Open Container Format (OCF) 3.0
http://www.idpf.org/epub/30/spec/epub30-ocf.html

[3] Microsoft Corporation: Open Packaging Convention, in: ISO/IEC 29500-2:2008, Information technology – Document description and processing languages – Office Open XML File Formats – Part 2: Open Packaging Conventions:
http://en.wikipedia.org/wiki/Open_Packaging_Convention

[4] ISO/IEC 26300:2006/Amd 1:2012 — Open Document Format for Office Applications (OpenDocument) v1.1
http://en.wikipedia.org/wiki/OpenDocument

[5] Adobe Systems: Universal Container Format
https://wikidocs.adobe.com/wiki/display/PDFNAV/Universal+Container+Format

[6] Sean Patrick O'Brien: iWorkFileFormat
https://github.com/obriensp/iWorkFileFormat/

[Mark Simonson]

Thanks for the responses, everyone.

I’m all for making the UFO format more in sync (heh) with modern practices, and I’m very much looking forward to Tal’s talk about it (I’m finally going to attend Robothon! Yay!), but I know that’s a lot of work and I’m guessing probably not going to be ready soon if it happens.

That said...

I’m looking for a more near term solution or workaround for my particular situation (and I imagine others may be in the same boat): I mostly work on my own (not often collaborating) and I have more than one computer.

I prefer working on files locally if I can rather than over a network, and I like to move between computers (mainly, a desktop on my desk top and a laptop when I want or need to work somewhere else). (Before anyone suggests it: I’ve tried using only one computer many times, but I’ve decided I don’t like that particular set of compromises.)

Dropbox has worked great for me for everything except UFOs. I could be wrong (I haven’t tried them), but I skeptical that other similar auto-synching services would handle frequent synching of thousands of tiny files any better. In fact, the last time I looked, Box didn’t even support packages.

I’ve been looking at git and I agree with David that it’s not really a good fit. I can see where it would make sense for font projects involving collaboration. But for my particular situation, it just seems to shift the burden off Dropbox and onto my shoulders.

I’ve heard of people using .zip files to store UFOs, and I do the same thing if I need to share one with someone over the internet, but as a method for synching UFOs among my Macs, it doesn’t sound very fun.

It occurs to me that .dmg might be just the thing. I’ve used disk images for various things for years, and I haven’t had any problems with them (yet). Dropbox doesn’t seem to have a problem with them, treating them like any other file. It wouldn’t matter that they contained UFOs, Dropbox would only see the .dmg, and that’s what it would sync.

A .dmg would be simpler to work with than a .zip. With a .zip, when you open it, it would create a directory full of UFOs, and if it’s unzipped in place in the Dropbox directory, you’ve got Dropbox trying to sync UFOs again. Unless you tell it to pause. And then you have to remember to tell it to resume.

With a .dmg, when you open it, it mounts a volume. The .dmg file is updated as you make changes to UFOs while the volume is mounted, and Dropbox will sync those changes.

The only drawback I can see is that you can’t mount the .dmg on more than one machine at the same time. This isn’t necessarily a bad thing and wouldn’t be hard to live with, all things considered. Each .dmg would basically be like a virtual thumb drive that resides on Dropbox (and therefore on all my machines) instead of my pocket.

Anyway, that’s what I’m thinking at the moment. I’m going to try it out and see what happens.

Mark

[Adam Twardoch (List)]

> On 12 Feb 2015, at 17:30, Frank Grießhammer <fran...@gmail.com> wrote:
> Robofont has gotten much better at not writing random data into .glif files; so it is nice to see which files a.k.a. glyphs have actually changed since the latest commit – I really would not want to go back to a big, binary MMVFB.

(...)

> I don't disagree that I/O speed is a problem with UFO. Opening a huge font is still much faster in FL; but I am glad to trade the binary “black box” for slower read/write speeds.
>
> Maybe there could be something like a binary UFO format for speed-critical operations; and a documented conversion utility? (of course, the conversion would need to go both ways, and is a bit risky — who doesn’t love a corrupted VFB).

I think there are two issues here which are getting a bit mixed up:
1. The question of "binary" (non-XML etc.) vs. "human-readable" (XML or so)
2. The question of "single-file" vs. "folder/package with multiple files".

As for (1), I don't think anybody really argues anymore that a "binary" format should be used. Fontographer chose a binary FOG structure and FontLab chose a binary VFB structure 20 years ago for various reasons, one being file size (fitting onto a floppy disk :D ). Compressed binary formats may be good for end-user delivery (OTF, JPG etc.) but I don't think many people would be advocating for them as a development format.

As for (2), it's a different question. .ufo is currently a folder with many human-readable files inside. The FontForge .sfd format and the Glyphs .glyphs format are human-readable but single-file (though FontForge does support a "multi-file" format as well, I think).

Apple iWork, Microsoft Office, OpenOffice/LibreOffice, EPUB store document in a "single-file human-readable" form in the sense that each of these formats is one ZIP archive that contains multiple files, many of them XML or in other human-readable, or at least, widely standardized formats.

I personally think that it would be nice to have an optional storage form such as .ufoz which would be simply the contents of .ufo stored in a single ZIP archive. I'd argue that this is not the same as "binary" in the sense you're describing.

Best,
Adam

[Frank Grießhammer]

Adam, correct. My mind wandered off toward this different (slightly related) problem.

Apple iWork formats such as Keynote are indeed XML in a container. 

This is all fine until there is a problem, and you actually have to work with the “human-readable” XML inside.

Just for the sake of curiosity: Mark – have you tried using iCloud drive?

Frank

[Tal Leming]

> On Feb 12, 2015, at 12:11 PM, Adam Twardoch (List) <list...@twardoch.com> wrote:
>
> I'm looking forward to your talk. I would be keen to hear what exactly makes ZIP an "absolutely terrible" choice.

That's not what I said. Here is my quote:

>> They are absolutely terrible, maybe unusably so, in a few ways.

I didn't say that they are a terrible "choice" and for the last 10 years I've been going back and forth on whether the benefits outweigh the problems or not. There are lots of things to consider.

(If you think I'm BS-ing you, look at the way ufoLib works in the ufo3 branch of RoboFab. I completely abstracted away direct file system calls in the external API. I was thinking ahead to a zipped version! https://github.com/robofab-developers/robofab/blob/ufo3k/Lib/ufoLib/__init__.py#L192 https://github.com/robofab-developers/robofab/blob/ufo3k/Lib/ufoLib/__init__.py#L701)

> Perhaps you might even choose to share why you think so despite the fact that Adobe, Apache, Apple, Microsoft and other major vendors widely chose a ZIP-based container as their storage format, and some even went through the process of international standardization.

Zips are very difficult to modify in place, or at least they were last time I looked into this. The format hasn't changed, so I'm assuming that hasn't changed. Anyway, what I mean is, you can't easily open a zip, modify a subset of its contents and then write it back in place. Zips need to be created from scratch each time. The formats that you mention are either single direction (read only) or are formats with a limited number of files to encapsulate. Even in the case of the iWork files, which include a subdirectory for the raw images placed into the document, the number of potentially likely images is far fewer than what is common in a single UFO. We're talking about thousands of files in a UFO versus dozens to hundreds in a Keynote file. With the UFO we have two kinds of authoring tool models:

- Some tools can read/write UFOs but only in an import/export capacity. These tools have their own file format that is independent of the UFO.
- A tool can use UFO as its native file format.

Zips are fine for the import/export model because the UFO isn't constant. It's only an occasional interaction for which a little progress bar can pop up while the Zip is created. In the native file format model, Command-S would need to pack up the entire Zip each time the user wants to save. Given the internal structure of the UFO, this could be an incredibly expensive operation. Yes, yes, yes, there could be optimizations and if this language is used and on and on. But, from a file spec point of view, it's complicated. There are some other issues, but come on, please don't make me give my whole presentation here. I don't have time to make another one. :-)

Again, I'm not saying "No!" to Zip. I'm saying that it's an imperfect solution among other imperfect solutions. There unfortunately isn't going to be a perfect solution. We just have to decide which imperfections are the least problematic.

Tal

[Adam Twardoch (List)]

> On 12 Feb 2015, at 18:34, Frank Grießhammer <fran...@gmail.com> wrote:
>
> Adam, correct. My mind wandered off toward this different (slightly related) problem.

:) Yeah, they are, indeed, related.

If someone wants "VFB-like" storage still, I think the right approach is custom SFNT tables (kind of like Adobe Illustrator PDF where "editing capabilities" metadata is stored inside the end-user-consumable binary container). That's the approach done in Microsoft VOLT and VTT. But I don't think many people are big fans of that approach anymore. Having your working project itemized sensibly (in a way similar to UFO) is a good thing, and I guess what people are wondering about is: do they really need to have it itemized ALL THE TIME? In my view, the ZIP container is a sensible compromise where you could have a ".ufo" folder or a ".ufoz" ZIP file, functionally identical with the only difference that one is a folder and one is a file (optionally compressed).

I'm leaning towards thinking: if *one* solution is not perfect for all, why not have *two* -- but perfectly convertible, or transformable, i.e. where only the "container" would be changed but no actual real data. To me, that's like "lossless compression/decompression".

> Apple iWork formats such as Keynote are indeed XML in a container.
> This is all fine until there is a problem, and you actually have to work with the “human-readable” XML inside.

Correct. But still, ZIP seems to be a reasonably robust container as far as I know. There are tools which can repair the ZIP container just as many as there are tools which can repair a "bad" folder or filesystem.

Again, I'm by no way an expert on this, I just happen to have noticed that Adobe (for PDF portfolio), Microsoft (for Office), Apache etc. (for OpenOffice), the e-book publishers (for EPUB) and Apple (in the past for iWork) all chose the same structure: a ZIP container with multiple subfolders and human-readable files, mostly XML, inside.

I simply assume that all these companies employ clever, intelligent people (much smarter than me) who know what they're doing, and that problems must have been ironed-out in the multiple standardization processes. Microsoft faced the same problem as FontLab with VFB -- corrupted binary .doc, .xls, .ppt files, and those problems were much more costly than ours. They switched to ZIP. Apple chose ZIP, Adobe chose ZIP (though only in a relatively obscure usage).

It would be great if the people on this list who happen to work in larger companies full of smart people could consult people from other departments who deal with document file storage for bigger projects (office apps, creative apps etc.). An independent insight could be invaluable.

Best,
Adam

[David Březina]

Thanks guys for considering this.

Frank, do not misunderstand me. I love Git! Git is Great. (Although not for everyone.) But I tried to say that move from Dropbox to Git would not solve the issue of having many files as opposed to one as there would be many files to stage (to use Git language) and that may be annoying. I will be at Robothon and happy to discuss it, so only briefly with a hope that some of this may be useful:

- I do not think that the option to copy glyphs between UFOs or versions of UFOs justifies this multitude of files. It is very rarely that you would correct a single glyph and without even looking at it in a font editor. Most of the changes are of global nature and affect multiple glyphs. Plus, you want to have a visual control.

- it would be lovely if Git dealt with packages in a smart way (tracking individual files and showing them optionally, but hiding them by default). Because packages are great too.*

- as Adam pointed out, it does not necessarily stand as one binary file contra multiple non-binary files, you can have one non-binary file too. I could imagine two flavours of UFO, one multi-file, one less-multi-file (i.e. with glyf data in one file or compressed), but still XML-based.

- to me package with few files (say under ten) is also a solution. Much more manageable. What these would be is up to the architects.

- that brings me to a point that this is also a question of tools (beyond editors). If there was a diff tool for UFO that would show you visually what glyphs changed (or even how)** between different versions of your UFO regardless whether it is single-file or multi-file there would not be much need to stick with the multi-file approach. That would help a lot, would not it. Leaving aside feasibility of it.

Cheers,

David

* Speaking of packages I remember that Subversion used to put hidden metafiles in them, so Git is indeed a step forward in that regard.

** I am thinking of a typical font view with a grid of glyphs where edited/deleted/added glyphs would be marked. Other stuff (font info, kerning, …) could be in separate sections. Upon clicking on a particular edited glyph you could even see overlay of the two versions of the edited glyphs. Just an idea to illustrate what I mean by more advanced diff tool. I take it there is diff for .glyf files somewhere, or only on GitHub?

[Ben Kiel]

Mark,

Like Frank, I’m finding git, using Bitbucket and SourceTree as a GUI for Git to be really good, even without collaborators. As Frank mentioned, it’s really good for tracking changes to a project over time, being able to go back in time to get a bit that you may have liked better in the past, etc. It is also great for working on two computers, you check in/out things (sorry, push/pull) via SourceTree, with everything living on Bitbucket. This has the nice advantage that I don’t have to keep everything on my laptop at all times to work, I can grab things as I need them.

That said, I do very much understand that git is awkward and weird. I was used to command line SVN, but command line git does my head in (perhaps it’s my head and not git). That is why I just use SourceTree. If dmgs work with dropbox, then I don’t think what you describe is unreasonable.

Best,
Ben

[Lasse Fister]

Hi Tal,

I'm forking the topic to drop you a note on what was happening here.

On 02/12/2015 06:50 PM, Tal Leming wrote:
> … in the ufo3 branch of RoboFab. I completely abstracted away direct

> file system calls in the external API. I was thinking ahead to a
> zipped version!
> https://github.com/robofab-developers/robofab/blob/ufo3k/Lib/ufoLib/__init__.py#L192
> https://github.com/robofab-developers/robofab/blob/ufo3k/Lib/ufoLib/__init__.py#L701)

I've been working in a similar direction, here's the state:

For ufoJS I made an IO-abstraction library where we can write custom
backends for many cases. So far there is
* a nodeJS `fs` module backend (write to disk from node js)
* a RESTful server API used via browsers AJAX (and the server backend
for nodeJS)
This one can also be used for read-only access of ufos from static
HTTP file servers, like if you put you ufo in a directory that is served
by Apache or `$ python -m SimpleHTTPServer`
* a small in-memory file system impementation

To enable downloads of ufos created within the browser and to open
uploaded ufos, we'll most certainly make a zip backend.

An abstraction like this could be done in Python as well. Also,
interesting for JavaScript, ufoJS can do synchronous and asynchronous
IO, but I think that is not so important for the cases where python is
used(?)


https://github.com/graphicore/ufoJS/tree/master/lib/tools/io
https://github.com/metapolator/metapolator/blob/master/app/lib/restfs.js
https://github.com/metapolator/metapolator/blob/master/app/lib/io/InMemory.js

L.

[Mark Simonson]

Frank,

I’ve thought about trying that, so I just did a quickie test:

- Folder 1 containing 9 files (JPEG and PDF), about 19,000,000 bytes consuming 19MB of disk space

- Folder 2 containing 10 UFOs (a little over 1000 glyphs each), about 19,000,000 bytes consuming 53MB of disk space

I moved these folders one at a time to both Dropbox and iCloud drive and timed how long it took to sync between two computers on the same network. Presumably, both work by uploading to “the cloud” on one end and downloading from “the cloud” on the other end. It doesn’t appear that either service took a shortcut over the local net.

Dropbox results:

Folder1 (JPEGs, PDFs): 

Upload = 49 secs; sync finished on other end = + 5 secs; 54 secs total

Folder 2 (UFOs): 

Upload = 530 secs; sync finished on other end = + 70 secs; 600 secs total

iCloud Drive results:

Folder1 (JPEGs, PDFs): 

Upload = 45 secs; sync finished on other end = + 20 secs; 65 secs total

Folder 2 (UFOs): 

Upload = 130 secs; sync finished on other end = + 120 secs; 250 secs total

So, based on this back-of-the-napkin test, Dropbox is a bit faster at synching typical files, but over twice as slow for UFOs.

I still have yet to try my dmg idea, but I need to eat lunch. I will be surprised if it’s not considerably faster than either of these, and would probably also work with either.

Mark

[Grzegorz Rolek]

On 12 Feb 2015, at 19:01, David Březina <bre...@davi.cz> wrote:

> I take it there is diff for .glyf files somewhere, or only on GitHub?

I remember Github used to render a glyph from a .glif file for both a single commit and a diff with two such renderings side by side, but this seems to be gone now, no?

But still, that kind of things were trivial for Github to implement exactly because there was one glyph per file and Github could simply trigger, as I imagine, a different rendering ‘plugin’ for what would normally be the usual textual diff for a file.

Regards,
Grzegorz Rolek

[Dave Crossland]

On Feb 12, 2015 1:01 PM, "David Březina" <bre...@davi.cz> wrote:
>
> Thanks guys for considering this.
>
> Frank, do not misunderstand me. I love Git! Git is Great. (Although not for everyone.) But I tried to say that move from Dropbox to Git would not solve the issue of having many files as opposed to one as there would be many files to stage (to use Git language) and that may be annoying

That's why you want to use a git client that works like DropBox where you don't have to think about it, like SparkleShare.

Git is more efficient with many small text files than a few large binary files; git-annex was developed for dealing with big binaries.

[Mark Simonson]

I’ve done some exploration into this UFO/disk image idea and have a few observations:

- Synching .dmg files containing UFOs is indeed faster than synching a folder containing the same UFOs.
- Dropbox and iCloud Drive were comparable in speed.
- When changes are made after the initial sync, they happen much faster, meaning that only the differences are moved to and from the sync server.
- .sparseimage files might make more sense since they use disk space more efficiently. That said, they can grow as files are added, but they don’t shrink as files are removed (even after emptying the trash).

The big drawback, and probably a deal-breaker, is that _no changes are saved to the disk image file_ until you unmount it*. It would be like working on a document and not saving until you quit, except it’s actually potentially a whole directory of documents. (I mentioned in an earlier message that disk images are updated as you use them, but I was mistaken about that, unfortunately.)

My vision was that I could keep all my font dev stuff on Dropbox (or whatever) by using this trick, but I think it’s probably too risky.

(* Only exception is when a .sparseimage grows, AFAIK.)

Thanks Dave, Frank, and Ben for the recommendations about git. It’s looking a bit more attractive now. Thanks also to Roberto for the .zip idea, although it seems a bit cumbersome.

Mark

[Mark Simonson]

Upon further exploration:

iCloud Drive may actually be the best option purely as an alternative to Dropbox for UFOs (setting aside git for the moment). Here’s why:

Unlike Dropbox, if you change the name of a folder, that’s all it does. Dropbox, on the other hand, sees everything in that folder (or package) as a new file to upload and sync. In other words, it acts as if you deleted the original folder and uploaded a new folder with a different name. This, I’m sure, is related to the way you can roll back and undo file deletions in Dropbox.

Even more, with iCloud, if you move a folder into some other folder, that’s all it does, and the change happens almost immediately. Done. With Dropbox, again it behaves like a delete/upload new stuff operation, taking just as long as the initial upload.

These two issues are the source of most of my Dropbox/UFO pain.

Add to this what I mentioned earlier about iCloud Drive synching UFOs over twice as fast, and I think this may be a viable solution for my situation.

Still going to look at git, but this has been illuminating. Did not expect iCloud to perform so much better than Dropbox.

Mark

[Mark Simonson]

There is one big problem currently with the idea of using iCloud Drive to house and sync UFOs: I can’t make TTFs using the UFO/AFDKO workflow I’ve been using if I keep my development directories there.

There is a bug in makeotf that causes it to fail to make TTFs if there are any space characters in the path to the working directory. The iCloud Drive directory is actually stored in ~/Library/Mobile Documents/… Note the space in directory name “Mobile Documents”. That will prevent makeotf from making TTFs. (No problem making OTFs, though.)

Until that bug is fixed, storing my development folders on iCloud Drive is not a viable alternative to using Dropbox, although it does work better in most other respects.

One caveat about iCloud Drive: It ignores resource forks, so it won’t properly sync legacy Mac files, such as font suitcases. They come up empty on the other end.

Mark

[Adam Twardoch (List)]

Mark,

1. Launch Terminal.app and make sure you're in your home folder (~).
2. Type in:

ln -s "Library/Mobile Documents/com~apple~CloudDocs" iCloud

This will create a symbolic link to your iCloud Documents folder so you'll be able to refer to documents in it using the shorter path such as:

~/iCloud/fonts/myfont.ttf

etc.

That was among the first things I did myself since I hate having to refer to the stuff inside my Library using explicit paths.

Best,
Adam

[Mark Simonson]

Hmm, that’s a very clever idea.

The thing is, the “build" script I use with makeotf (written by Ben Kiel—thank you, Ben!) is designed in such a way that it uses the directory it resides in as a basis for all the paths it uses, which are generally directories below it in the hierarchy. So, all I do is keep the build script at the top of my working directory (wherever that may be) and run it from there, usually using TextMate. I can use the same exact script for any set of directories containing UFOs. There are no explicit paths specified in the script.

There is probably a way to modify the script to use a symbolic link, and I’ll look into that, but it’s still just a workaround for a bug. It would be better if the bug in makeotf were fixed. That affects more than this particular case and there seems to be no good reason for it.

Mark

[Dave Crossland]

On 18 February 2015 at 13:42, Mark Simonson <mar...@bitstream.net> wrote:

The thing is, the “build" script I use with makeotf (written by Ben Kiel—thank you, Ben!)

Is this published? :) 

[Mark Simonson]

No. He wrote a custom script for me to meet my particular requirements, for which I paid him.

Mark