On Tue, 2008-05-27 at 08:24 +0200, Hans Hagen wrote:
how do they deal with non compatible new features; for instance, at bachotek i learned that some otf features that are not supported in older versions are supported in new ones (or are supported differently); is there some compatibility mode (i.e. is the old behavior still present and the ID/IC version number stored in the document?)
I asked those wiser than I and this is what professional expectations tend to be: 1. Versioning within a document (track changes) basically becomes a non-entity by production; that is local and removed within a production cycle and tends to be wholly separated from version issues. Also, product cycles are generally tagged to a version of a program and therefore multiple versions need to be able to coexist in the case where the new version may not be backward-compatible with the old. With Quark, one could only count on backward compatibility over one version bump. After that, compatibility would diminish so that Quark 4.0 would not open Quark 1.0 docs. Makes Microsoft's format versioning seem positively user-friendly by comparison. The firm I work for has only started with the current InDesign/CS3 suite and relies on the quark plugin to do the work. Especially in Quark, third-party plugins were the most fragile. We expect, however, that Indesign will probably follow Quark in failing to be too bacwardly-compatible, opening well only the prior version docs and then saving them as current. That's one of the things that drove my personal computing away from Windows to Linux/FreeBSD. I was using an English firm's Creative Suite knock-off product (Serif) and realized that their business plan called for making shoddy products and substituting version bumps for bugfixes. I can only bleed so much to sate someone's greed and I found OSS to be far friendlier regarding version compatibility, bugfixes and robustness. AFAIK no real pressure for a compatibility mode exists in the commercial DTP sector. senecadesign.com has good InCopy resources and archives. Charles
participants (1)
-
Charles P. Schaum