Am 2018-02-27 um 16:10 schrieb Alan Braslau :

...

With \setupbackend[export=yes] the image is placed "here" and never "right" or "left".

I "reported" this a while ago. The answer is that right or left are meaningless for the export and that the export is built somehow using the generated PDF. ... I believe that Hans' workflow includes controlling the export run by viewing the export PDF (in sumatra), so he has been reluctant to change the behavior.

Hi! Slowly recovering from the flu... So, this is already known. But if there’s indeed such reasoning behind, it really makes no sense at all! Even if Hans’ workflow is not capable of right or left placement, it’s easily achievable in HTML/ePub (CSS float: left/right), so it can’t generally be meaningless. And I can’t accept that the option of exporting to XML would (more or less) drastically and needlessly change the print layout! At least _please_ make it an option! Greetlings, Hraban --- http://www.fiee.net http://wiki.contextgarden.net GPG Key ID 1C9B22FD

On Sat, 3 Mar 2018 10:47:52 -0500 (EST) Aditya Mahajan wrote:

On Sat, 3 Mar 2018, Henning Hraban Ramm wrote:

...

And I can’t accept that the option of exporting to XML would (more or less) drastically and needlessly change the print layout! At least _please_ make it an option!

In the meanwhile, you can do:

\startmode[export] \setupbackend[export=yes] \stopmode

and then run with `--mode=export` to get the export and without that option to get the print layout.

Aditya

And, unfortunately, this "breaks" the PDF. Of course, one can always write a script that moves the PDF to a safe place, etc. but this is not ideal. Alan

Am 2018-03-04 um 10:49 schrieb Hans Hagen :

On 3/3/2018 5:13 PM, Alan Braslau wrote:

...

On Sat, 3 Mar 2018 10:47:52 -0500 (EST) Aditya Mahajan wrote:

...

On Sat, 3 Mar 2018, Henning Hraban Ramm wrote:

...

And I can’t accept that the option of exporting to XML would (more or less) drastically and needlessly change the print layout! At least _please_ make it an option!

In the meanwhile, you can do:

\startmode[export] \setupbackend[export=yes] \stopmode

and then run with `--mode=export` to get the export and without that option to get the print layout.

Aditya And, unfortunately, this "breaks" the PDF. Of course, one can always write a script that moves the PDF to a safe place, etc. but this is not ideal. normally you will run like "context --mode=export --result=myexport" or so where you wrap settings specific to an export in modes

I (can) run several "results" for most of my projects, e.g. lowres, print res, imposed (arranged) and epub. But I insist it makes no sense that (epub) export breaks image placement in the pdf. Why add another lengthy TeX run?

the more features we add to mtxrun the more complex it will become (and no one will use them then)

Hans, please, it’s not about adding features, it’s about an existing feature that unnecessarily influences/disables an other. Greetlings, Hraban --- http://www.fiee.net http://wiki.contextgarden.net GPG Key ID 1C9B22FD

On 3/4/2018 4:15 PM, Alan Braslau wrote:

On Sun, 4 Mar 2018 13:51:39 +0100 Henning Hraban Ramm wrote:

...

...

normally you will run like "context --mode=export --result=myexport" or so where you wrap settings specific to an export in modes

I (can) run several "results" for most of my projects, e.g. lowres, print res, imposed (arranged) and epub.

But I insist it makes no sense that (epub) export breaks image placement in the pdf. Why add another lengthy TeX run?

Because when one really wants a proper structured file from a source one should also to some respect adapt the style for that run. Also, 'lengthy tex run' is no argument (most of my tex runs are not that slow ... it also depends on the efficiency of styling) ... and when working on a document i'd never generate an export every run (as the export itself adds 20% overhead!) ... if i care about an export at all, it's an extra run in a workflow (idem for other products).

...

...

the more features we add to mtxrun the more complex it will become (and no one will use them then)

Hans, please, it’s not about adding features, it’s about an existing feature that unnecessarily influences/disables an other.

In this case it's disabled because the result is a garbled export and you don't want that either do you? We need to play safe. I might spent time on if some customer would demand it and pay for it but i never ran into a customer who had any demand for export (of advanced pdf).

I do this (--mode=export --result=exported) and find it somewhat awkward. I also do not understand why one should not/cannot export systematically, thus creating multiple output, nor do I "really" understand why exporting *has* to break the floats (and what else?).

The export is a structured export so one one has to handle rendering (and float placement) in a css or wherever .. turning rendered side float placement into something export is asking for troubles (as lots of - also out of sequence - shifting around etc happen, e.g they can end up in the margin in which case flushing happens completely different) and i don't look forward to a decade of answering why this or that doesn't work out as expected (the same is true for tables and itemize and ... : you get the structure as good as possible from what is basically a reverse engineered rendering) ... so, instead you should wonder why the export works at all

As a result, this is a *feature* (export) that I can but rarely use. Normally one will have a neutrally encoded source that can become anything you want.

Basically the export is a side effect of tagged pdf which is also a lunatic feature only in pdf because publishers don't want to distribute a proper source which would be way more powerful to re-render and as said i never had to produce either tagged of exported content myself (which would then give me feedback about what could be done better). Btw, try to reverse engineer a realistic picture of your house from an abstract painting of that same house ... Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On 3/3/2018 11:07 AM, Henning Hraban Ramm wrote:

Am 2018-02-27 um 16:10 schrieb Alan Braslau :

...

...

With \setupbackend[export=yes] the image is placed "here" and never "right" or "left".

I "reported" this a while ago. The answer is that right or left are meaningless for the export and that the export is built somehow using the generated PDF. ... I believe that Hans' workflow includes controlling the export run by viewing the export PDF (in sumatra), so he has been reluctant to change the behavior.

Hi! Slowly recovering from the flu...

So, this is already known. But if there’s indeed such reasoning behind, it really makes no sense at all!

Even if Hans’ workflow is not capable of right or left placement, it’s easily achievable in HTML/ePub (CSS float: left/right), so it can’t generally be meaningless.

it has othing to do with that but more with the fact that the actual placement can make the structure invalid

And I can’t accept that the option of exporting to XML would (more or less) drastically and needlessly change the print layout! At least _please_ make it an option! ok, i'll remove the check ... but: don't bother to complain about invalid exported structured when it happens as i will not look into and/or fix interferences with the actual placement, which can be elsewhere due to lack of room or delayed placement due to margin locations (in that case you need to make a conditional sections in your document source)

Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------