[scribus-dev] Fwd: Great meeting you in Saarbrücken

Gregory Pittman gpittman at iglou.com
Mon Jun 10 22:57:20 UTC 2019


On 6/10/19 10:27 AM, Tamir Hassan wrote:
> Hi Leonard, hi all,
> 
> On 6/7/19 5:03 AM, Leonard Rosenthol wrote:
>> I do indeed, Tamir -= great to see you continuing to work on this.
>>
>> Certainly interested in hearing what you think you'd like to achieve and then trying to make it so...
> 
> For the benefit of everyone else on this list, when Leonard and I spoke at PDF Days 2018 in Berlin, I proposed the idea of extending the PDF spec to support the embedding of sufficient metadata that would make it possible to edit the document in some sort of "standardized" way. We would then finally have a way to exchange editable documents with others with robust layout and the other features of PDF - no other format offers this.
> 
> Obviously, most applications have their own proprietary format and their own internal models of the document structure. But there are very many similarities among the various canvas-based document formats and, just like PDF is a common standard for final form documents now, wouldn't it be great if there were a common standard for editable documents too?
> 
> There has been some previous work in this area. I've been told that Adobe Illustrator's Interchange PostScript, one of PDF's forerunners, was an attempt at a platform-independent, editable format. And PDF today at least supports tagging, which provides for standardized markup of logical structure elements. However, in order for a document to be editable, you need not only the logical structure, but also the stylesheet and/or layout rules. OpenOffice has also had the option to generate "hybrid PDFs" since around 2008 or so, which contain the ODF source in one of the content streams, but the robustness is lost when the document is opened for editing.
> 
> I have a lot of experience with automatic text typesetting, and this is where I see the biggest challenges in engineering a robust, yet editable document format, as there are often small, microtypographic differences between how different programs set text. But there is also a lot of inherent flexibility in setting text (see Hassan and Hunter 2015, linked below), and as long as the positions of the line breaks are stored in the PDF, it should be possible to re-set the text for editing using a different algorithm that maintains the line breaks and avoids major changes in layout.
> 
> Of course, when substantial edits to the text are made, text will have to reflow, which it should do in a predictable way according to a standardized layout model made up e.g. of either linked frames (typical DTP model) or X-Y page divisions (typical WP model).
> 
> PDF has long been under threat from Web standards, but I would hate to lose the robustness and archivability of PDF when HTML finally replaces it. This is why this idea is more about bringing the two worlds closer together, marking up the content in a similar way to HTML, styling it with CSS or similar, but encoding additional information about e.g. line breaks to ensure layout robustness and typographic fidelity.
> 
> At DocEng 2018 I published a paper on this topic and also coded up a basic prototype to illustrate the concept (see links below). But there is still a lot of work to be done and it would be great to have the cooperation and input of the various stakeholders in defining the format.
> 
> During the discussions at Libre Graphics, it was suggested that, if we could get Scribus, Inkscape and Libre Office to agree on a common model, then this would be a great first step that could get things going.
> 
> So this is why I am posting here, to see if this idea can gain traction and discuss the next steps. Perhaps now would be a good time to revisit the concept of Interchange PostScript in the light of how web standards have changed in the meantime.
> 
> Further reading: https://editablepdf.org
> For references, see https://editablepdf.org/references/
> 

Hi Tamir,

I don't know if you've taken a look at it, but here is the file format specs for Scribus 1.4 files:

https://wiki.scribus.net/canvas/File_Format_Specification_for_Scribus_1.4

There's a lot that is not documented on this page, but it illustrates the extensive amount of information potentially contained in a Scribus XML-like file. If you don't have a good part of this, you end up with what we might call PDF-lite, or perhaps a more robust markdown-like system.

Are you planning on doing things like layers, like color management? Text kerning?

Greg




More information about the scribus-dev mailing list