faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
KOffice & Scribus
by jameth on Saturday 12/Feb/2005, @08:07
|
I've been using Scribus a bit lately and am very impressed. I think it would be really cool if it could be worked into the KOffice suite of tools. I'm not saying that the stand-alone version should go, or even be secondary, but something more along the lines of the enable=KDE configure flag.
If this were done right, I might finally be able to get the working environment I've always wanted, which is to have a light and reliable word processor to allow me to lay down some text, followed by a seamless switchover to a layout program that can work on the exact same file. That division of tasks can be just wonderful for someone who really wants to work at a professional level.
(On a side note, if Scribus could get QuarkXpress and InDesign file support, that would be a godsend for me. I am still at college and am often stuck working on one of the school computers and need to use one of those programs if I want to do layout. I usually end up just using a text editor and trying to ignore the layout until I get home and can merge it into my main project, but that is very far from optimal.)
Overall, thanks for a wonderful tool! |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Quark and ID file import
by Craig Ringer on Sunday 13/Feb/2005, @07:06
|
Support for importing Quark and InDesign files is a common request. Unfortunately, I sincerely doubt it'll ever happen for a couple of reasons.
The first is getting it right. If you think OpenOffice has trouble with MS word, imagine something _massively_ more complex, with a format that changes dramatically version to version, whose users won't tolerate a 0.01mm misalignment. Then think about doing it twice. OpenOffice has been trying to get MS Word import right for years - and with a lot more manpower than Scribus has behind it too. This should give you some idea of the magnitude of this task.
It doesn't help that, in my view at least, inaccurate import can be worse than no import at all.
Think of it this way. Adobe InDesign can import Quark 4 ... but it doesn't get it right all the time, and doesn't support all of the format. Adobe is a large company that spent a huge amount of resources on that. The ability to import Q4 was one of the big things folks needed to transition from Q4 to InDesign ... and even then Adobe couldn't get it to work all the time. It's hard.
The other issue is legal/risk. Adobe and Quark aren't what you'd call friendly, chummy folks who're easy to get along with. They might also be a bit unhappy about file format support, even if it was perfectly legal reverse engineering. Personally, I don't like the idea of being sued by Quark - even if there's no reasonable leagal basis, how often does that actually _matter_? Bankrupt is bankrupt.
Personally, I think it'd be cool to support slurping text and images from Quark 6's XML export format (it's made for interoperation after all, right?) to build the skeleton of a Scribus document. Anybody who wants to look into this need only write a plug-in - Scribus plug-ins become fully functional parts of the application, so you can do whatever you need to.
The format it'd be really cool to be able to import - at least the text, graphics, and rough layout - would be Quark 4. Alas, as anybody who's worked with Quark for long will know, Quark 4 can't always import that reliably :-P . It's an undocumented (as far as I know, anyway) binary bundle of fun, and in my opinion probably a lost cause from an import perspective.
My comments here are, of course, just my personal opinion.
|
[
Reply To This | View ]
|
Re: Quark and ID file import
by Chris Ryland on Thursday 17/Feb/2005, @17:35
|
I'm pretty sure that Quark has said publicly that V7 will have a full XML representation of documents as a save option. So there's a fighting chance there.
And InDesign CS and later have an "XML binary dump" format called INX which would be a start for importing the basics, though it really has a lot of binary aspects to it.
Finally, note that InDesign CS and later have a full cross-platform Javascript scripting implementation (they call it ExtendScript, but it's just the Netscape Javascript engine at heart), and it's quite powerful and very good.
|
[
Reply To This | View ]
|
Re: Quark and ID file import
by Bob Claborne on Thursday 24/Feb/2005, @16:52
|
Craig,
A most interesting perspective. I can tell you from experience that you are certainly correct. It is hard, very hard to do.
We have had some experience in the file conversion business ourselves. Two successful commercial products in fact, although they go in a different direction... PageMager to Quark and InDesign to Quark.
The tricky part, as you correctly pointed out, is that these DTP formats are proprietary and thus generally unintelligible. We have over 10 years experience with this sort of thing and have learned the file format layouts of most of the popular DTP applications including Quark.
Our original purpose (and that for which we are best known) is to preflight these files. That is to say, inspect them for design elements that would cause a print output problem for a commercial printer.
Since we can "see into" these file formats, we have now turned this patented technology towards extracting the content into XML. Our goal is not just the content but the layout, page geometry, font use, text and image box positions and size, etc. In short, XML tagged with all the formatting information one would require to reconstitute the original document in another application. So, Quark to XML to InDesign for instance.
You mentioned "...slurping text and images from Quark 6..." which is essentially, what we can do today (for Quark V3.1 to 6.x). In addition, we have developed a plugin for InDesignCS that can read the resulting XML and reconstruct the document.
Of course this is still a work in progress and, as you mentioned, there are many factors (and customer expectations) to be considered. I can certainly understand the context of your comment "...inaccurate import can be worse than no import at all..." but cannot completely agree with it. Our considerable experience with our other conversion products has taught us that some reasonable degree of accuracy is far better than doing the document over from scratch.
Nevertherless, your point is well taken and we are determined to overcome the barriers.
Our conversion philosophy goes beyond simply converting X2Y. There are hundreds of hungry XML enabled applications out there and thousands of potential customers with vast libraries of legacy DTP content they would like to feed into their variable data publishing, content syndicating, content repurposing, et.al. engines and we aim to supply the XML conversion technology to emancipate that proprietary content.
Did I mention that this is not an XTension? We can inspect and convert these files as a stand-alone application.
Anyway, it is a rather significant challange but there is hope. If you would like to "...slurp text and images from Quark..." and import them into InDesignCS, drop me a note and I'll provide a ßeta of our application, code-named XMLazarus.
Regards,
Bob Claborne
Director Business Development
Markzware
|
[
Reply To This | View ]
|
Re: Quark and ID file import
by Steve Marshall on Thursday 23/Feb/2006, @04:05
|
Bob
Your XMLazarus looks like it would have a lot of untapped market potential.
Extracting the text and graphics is exactly what we have to do to be able to recycle our OWN stuff - sometimes I print it then OCR to avoid having to get in the queue for DTP time!
If you could put us down for a beta we'll give you some feedback
Steve
|
[
Reply To This | View ]
|
|
Re: KOffice & Scribus
by pj on Friday 01/Jul/2005, @04:33
|
You could probably write an XSL filter. XSL allows you to transform one XML into another. Try to get more information about it, it's all on the web, and it's probably able to do what you need.
XSL is kind of a transform definition to pass from XML to other formats.
There are free tools you can use to actually apply the XSL to an XML file to get the desired output.
So this procedure can act as the bridge you want.
Of course, one needs to know the source and target file formats in order to construct this XLS transformation definition file. But it should not be difficult to get startet if you simply look at some sample XML files of the two programs you want to bridge.
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
