>
> dear scribuser,
>
> today @ LGM, i've attended the libreoffice conference on file formats
> reverse engineering. fridrich and valentin were proud of the fact that
> scribus has started implementing the support for using their library to
> import publisher files.
>
> and now they want bug reports!
>
> so if you have access to publisher files, please get the scribus trunk,
> compile it, import your files, report bugs on what does not work as you
> would expect!
>
> if you want help out, please get in touch with me, so that we can find
> out how the process should work.
>
> if you can't compile the scribus trunk, we should be able to find a
> solution: don't worry!
>
>
> and there are good news for the future, too!
>
> i've asked, what they would think about reverse engineering the
> indesign file format.
> and they didn't say no :-)
>
> but they need one or more people preparing for them lot of test .idd
> files.
> those files will have to introduce one element at a time (and be
> accompanied by a description of what the file contains. as a text file:
> fridrich and valentin won't be able to see the content of your file
> before having reverse engineered it!).
>
> it's a lot of work also for the person(s) preparing the file and it
> requires:
> - having a copy of indesign (if possible correctly licensed)
> - being willed (and skilled) to do very systematic work
>
>
> any volunteer?
>
>
> greetings from madrid
> a.l.e

This is good news. There are certainly Scribus users, including myself (JLuc 
and Cedric also come to mind), who can contribute *.indd files. However (and 
this is no criticism), other formats may be more important. Please let me 
explain:

1) In version CS 3 or 4, Adobe introduced a fully documented XML version of 
InDesign's format (IDML), so exchange between programs supporting IDML is 
already facilitated. The IDML spec should also help re-engineering INDD files.

2) Before IDML, Adobe used INX for data exchange, another XML representation of 
INDD file, but never completely documented. Users of older versions of InDesign 
may welcome an INX library and related documenation.

3) Let's be honest: InDesign is the Platinum standard of DTP software. While 
Scribus provides many features that InDesign doesn't, InDesign offers many more 
features that Scribus doesn't (yet). So, realistically, we should look at users 
of other programs first, especially those who might consider or are being 
forced to switching their software. The most important programs in this 
category are QuarkXPress and PageMaker.

4) PageMaker has reached its EOL, so it would be possible to re-engineer 
existing files from version 1.0 to the latest version. I have a licensed copy 
of 4.0 for Windows 3.1 (which I can run under eComStation), while other 
subscribers have newer versions, IIRC.

5) QuarkXPress allows for exporting XML versions of QXD files (QXML) since 
version 7. Unfortunately, the publicly available version of the spec has been 
retracted and made a part of the XPress SDK. Access to the SDK requires an 
up-front payment of several hundred $$/??, but someone with access to a recent 
version XPress could create the test files required to analyse the XML code, 
which might in turn help to re-engineer QXD files.

6) Another approach to re-engineering XPress may be QXD files from older 
versions (XPress 3 or later). File formats rarely change dramatically over 
time; they rather tend to evolve, so starting with an older and thus limited 
version may help. Remember that Adobe and Viva emphasised their support of 
XPress 4 files after XPress 5 was released, because the disaster that this 
version was for Quark seemed to be a great opportunity.

7) Today, Quark's focus seems to be on automated document generation and 
cross-media publishing, whereas the individual designer seems to be an 
afterthought. Thus, re-engineering QXD to allow former XPress licensees using 
their files in other programs (LibreOffice, Scribus) looks like a promising 
endeavour.

8) There are also other DTP programs whose file format spec is either 
published, or who provide an XML version of their formats (albeit 
undocumented). See: 
http://wiki.scribus.net/canvas/File_formats_that_should_be_supported_by_Scribus_(wish_list)#DTP

All of the above would deserve import/export libraries.

My 2 ct.

Christoph

Reply via email to