Altium seems to do poorly with new products. In the past they were rolled out separately from the core product AD. CircuitStudio, NEXUS, NanoBoard, TASKING... all were hyped and then faded away. AD kept going. This time, Altium is messing with the heart of the business and I don't expect if will go well. Looking at the big picture, I put most of the blame on the PCB industry leaders (IPC included) for not pushing for data standards that ensure portablity of designs between EDA platforms. This should have happened over 10 years ago. IMO, KiCAD has the best shot at establishing this now. I wish that would be a priority for them and some others.
That's a pipe dream.
Something I think a lot of people don't understand is the fact that a file format generally reflects the internal object model of the program the format was created for -- and that converting from one object model to another is difficult at best and impossible at worst!
I'll give an example from a different discipline: word processing. Seems easy enough, right? Some text and some formatting? No big deal!
Except that it is. In a tag-based format (like classic HTML, RTF, WordPerfect, or BBcode for this forum), you have opening tags and closing tags. Simple enough. But to correctly determine the formatting of any piece of text, you must parse the entire preceding text, since an opening tag could exist anywhere before the text in question. Now, this is no big deal if your document is 10KB and your available RAM is 100MB. But what about a 100KB document on an early-80s computer with 128KB RAM? Or, for that matter, a hypothetical 100GB document on a system with 16GB RAM? Now you're in trouble because you either a) have to load the whole document into RAM and you now can't, or b) you have to parse the document by reading it in from the beginning each time, ruining performance.
A guy named Charles Simonyi came up with one solution, which got used when Microsoft hired him and he worked on Word: separate text and formatting. In Word, a document breaks several assumptions one might make about a text document: 1. that the text in the file is in the same order as the text in the document, and 2. that the formatting is stored together with the text it formats.
In Word, a document is actually closer to a lightweight filesystem, containing (among other things) chunks of unformatted text, a list of "stylesheets", and an index indicating the order of text chunks and the stylesheet associated with each one. Only the index needs to be loaded into RAM; the rest can be loaded on-demand to render a given page. This decoupling of storage and presentation is such a core feature of the Word "engine" that it makes import and export rather difficult; it's taken years and years to get it to work decently, and it's still imperfect.
Rendering for presentation is one thing. But making a conversion fully editable becomes a whole nother can of worms. (Ever wonder why PDF editing -- or even just selecting text to copy -- is so weird and unpredictable? PDF was never designed as a word processing format, so every single character on the page is placed individually, with no concept of a word, never mind a sentence or paragraph. When a PDF viewer lets you select text sensibly, it's because they put a huge amount of effort into trying to piece together a flowing text out of a bunch of random letters scattered on the page. I wouldn't be surprised if some viewers just use OCR under the hood... Editing text, such that it reflows onto new lines, is a gargantuan effort.)
Another issue with (fully editable) file formats is that the format must necessarily reflect every feature in the program that edits it; if it didn't, you couldn't allow full editing. Another Microsoft Office example: Early versions of Excel for Mac used the Mac system software's native date epoch, which starts on January 1, 1904. The DOS/Windows versions used Microsoft's epoch that started on January 1, 1900. Both versions saved the value directly in the file. So once they added cross-platform file compatibility, the file format had to support either epoch (it's a flag it sets) so that the calculation engine can convert appropriately.
It gets better: there's also a flag for Lotus 1-2-3 dates, and what that mode does is indicate "this file was imported from Lotus 1-2-3, which has a bug in its leap year handling", instructing the calculation engine to
mimic the Lotus bug so that the file opens without changes.
The effect of all this is that standardized, non-proprietary file formats simply cannot, and do not, allow lossless data editing from one program to another. Any feature present in one program, or even just implemented in a fully different way, cannot be properly represented.
Home
Help
Search
Login
Register
