<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, 11:23:<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/13/19 10:36 AM, Andreas Vox wrote:<br>
>     Combining this with interactive, WYSIWYG editing is a different<br>
>     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.<br>
> <br>
> <br>
> Scribus already does it that way.<br>
<br>
I am not that familiar with Scribus, but I was talking about float <br>
placement and other global optimizations. Even LaTeX only uses a greedy, <br>
list-based algorithm for this.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Scribus doesn't support automatic float placement, yet. If it did, updating the floats would probably delayed until the user left the current paragraph or even left edit mode. </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>
> Substituting the font without reflow usually makes the document useless <br>
> for professional use. Scribus allows editing with substituted fonts and <br>
> changes them back when they become available, but text layout is always <br>
> done with the substituted font's metrics.<br>
> Editing a document without having the used fonts available is always <br>
> suboptimal and should not be encouraged. Permanently substituting <br>
> missing fonts with an available one is the better choice unless you have <br>
> a workflow where users have  different font sets and the final layout is <br>
> done by someone who has all the fonts.<br>
<br>
Yes, that's what I was getting at. Working on a document e.g. in a <br>
corporate setting with licensed corporate fonts, but together with <br>
people from outside of the company. You could send them the document <br>
with embedded metrics and they will be able to edit it using a <br>
substitute font, and when they return it to you the typesetting will be <br>
flawless again.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If you embed the metrics you might as well embed the whole font. </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>
> Speaking of workflows: what kind of workflow do you want to support with <br>
> editable PDF? Touching up a document at the print shop? Providing <br>
> collaboration between authors who use different page layout <br>
> applications? Allowing to reuse an existing PDF later for a new project?<br>
> To me, avoiding reflow only makes sense for the first of those.<br>
<br>
I don't agree. My background is in research and I have often worked on <br>
papers and grant applications together with other researchers. Such <br>
documents often contain many figures and tables, which are often <br>
floating (that's a nice optimization problem here).</blockquote></div></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">
Anyway, as the document is authored and the text gradually gets closer <br>
to the final version, the layout also starts to take shape, and I have <br>
always edited text hand-in-hand with the layout. If I were to send the <br>
document to a colleague to e.g. edit section 3 of the paper, it would be <br>
irritating if it would come back with sections 1-2 reformatted and lots <br>
of whitespace where the text did not quite fit its allocated space.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Wouldn't it be more useful to lock some pages so their layout stays fixed? </div><div dir="auto"><br></div><div dir="auto">If text is always reformatted, there won't be any irritating white space except at the end of an article. </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">
I can only imagine that, for more graphical publications, such as <br>
textbooks in e.g. education and magazines, this becomes even more <br>
important. The current workflow where the author only uses a word <br>
processor and sends files back and forth to a graphic designer is not <br>
very efficient; it would be much better if both could edit the same <br>
document (simultaneously, even).<br> </blockquote></div></div><div dir="auto">As far as I know, in professional workflows for more graphical applications designers/authors use the same software, and page ranges are assigned to individual contributors. </div><div dir="auto">Publishing houses usually enforce a single file format for authors, either MS Word or a TeX variant. </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">
</blockquote></div></div></div>