<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Tamir Hassan <<a href="mailto:dev@tamirhassan.com">dev@tamirhassan.com</a>> schrieb am Do., 13. Juni 2019, 09:14:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andreas,<br>
<br>
On 6/11/19 8:20 AM, Andreas Vox wrote:<br>
> I think it's only possible to achieve two of the following: editable, <br>
> stable layout and optimal layout. If you modify a document in another <br>
> application than the one which produced it, there will always be <br>
> difference in appearance, functionality or both.<br>
<br>
I'm not quite sure what you mean by "optimal layout", but of course, I <br>
am trying to achieve the first two here. Opening a document for editing <br>
should not cause any reflow changes until the content has been edited, <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That would imply that applications support a "frozen text layout" in addition to their usual layout algorithm. Doable, but I'm not convinced that the benefits outweigh the drawbacks. For one, users have to be aware which frames are frozen and which ones use the application's native layout. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and then it should reflow in a predictable manner.<br><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote></div></div><div dir="auto">That would mean standardizing the layout algorithm. On a per-application basis the reflow is already predictable - I'm not aware of any software that randomizes text layout :-) </div><div dir="auto"></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Optimal layout for me is not only the use of local and global <br>
optimization algorithms such as Knuth-Plass on the paragraph level, but <br>
also stuff such as pagination and figure placement on the global level. <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Agreed. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Combining this with interactive, WYSIWYG editing is a different problem, <br>
as everything would be jumping about from page to page every time a <br>
single character is typed, assuming the computation can be done fast <br>
enough.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Scribus already does it that way. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> It would probably make the most sense to carry out global <br>
optimizations on demand once the content is known, and only locally <br>
optimize during editing (if at all.)<br>
<br>
> But there's definitely a lot of opportunity to improve editing PDF if <br>
> you accept adequate layout changes. IMHO, reflow, font substitution, <br>
> change of color model, change of resolution and scaling are acceptable <br>
> layout changes. Missing content, inconsistent line breaking or <br>
> distortion are obviously not acceptable.<br>
<br>
I wouldn't describe some of these as layout changes at all. But yes, if <br>
a font is substituted (PDF already provides mechanisms for this), this <br>
should not cause reflow and, in fact, if the font later becomes <br>
available again it should be substituted back.<br>
 <br></blockquote></div></div><div dir="auto">Substituting the font without reflow usually makes the document useless for professional use. Scribus allows editing with substituted fonts and changes them back when they become available, but text layout is always done with the substituted font's metrics. </div><div dir="auto">Editing a document without having the used fonts available is always suboptimal and should not be encouraged. Permanently substituting missing fonts with an available one is the better choice unless you have a workflow where users have  different font sets and the final layout is done by someone who has all the fonts. </div><div dir="auto"><br></div><div dir="auto">Speaking of workflows: what kind of workflow do you want to support with editable PDF? Touching up a document at the print shop? Providing collaboration between authors who use different page layout applications? Allowing to reuse an existing PDF later for a new project? </div><div dir="auto">To me, avoiding reflow only makes sense for the first of those. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
</blockquote></div></div></div>