Try to compile this with and without the first line:
\setupbackend[export=yes]
\starttext
\input tufte \placefigure[right]{}{% \externalfigure[hacker][width=.33\textwidth]% }% \input tufte \input tufte
\stoptext
With \setupbackend[export=yes] the image is placed "here" and never "right" or "left".
Greetlings, Hraban --- http://www.fiee.net http://wiki.contextgarden.net GPG Key ID 1C9B22FD
On Tue, 27 Feb 2018 15:41:41 +0100 Henning Hraban Ramm texml@fiee.net wrote:
Try to compile this with and without the first line:
\setupbackend[export=yes]
\starttext
\input tufte \placefigure[right]{}{% \externalfigure[hacker][width=.33\textwidth]% }% \input tufte \input tufte
\stoptext
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 requested that this PDF be placed in the export (sub)directory so as not to "break" the PDF produced on a previous run without export. I can deal with multiple runs when exporting, although ideally one could decide to export systematically and the process would produce two PDFs including the one used in creating the export. If this seems awkward or clumsy then at least preserving the "production" PDF would be desirable.
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.
Alan
Am 2018-02-27 um 16:10 schrieb Alan Braslau braslau.list@comcast.net:
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, 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
On Sat, 3 Mar 2018 10:47:52 -0500 (EST) Aditya Mahajan adityam@umich.edu 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
On 3/3/2018 5:13 PM, Alan Braslau wrote:
On Sat, 3 Mar 2018 10:47:52 -0500 (EST) Aditya Mahajan adityam@umich.edu 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
the more features we add to mtxrun the more complex it will become (and no one will use them then)
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 -----------------------------------------------------------------
Am 2018-03-04 um 10:49 schrieb Hans Hagen pragma@wxs.nl:
On 3/3/2018 5:13 PM, Alan Braslau wrote:
On Sat, 3 Mar 2018 10:47:52 -0500 (EST) Aditya Mahajan adityam@umich.edu 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 Sun, 4 Mar 2018 13:51:39 +0100 Henning Hraban Ramm texml@fiee.net 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?
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.
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?).
As a result, this is a *feature* (export) that I can but rarely use.
Alan
On 3/4/2018 4:15 PM, Alan Braslau wrote:
On Sun, 4 Mar 2018 13:51:39 +0100 Henning Hraban Ramm texml@fiee.net 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 -----------------------------------------------------------------
Am 2018-03-03 um 16:47 schrieb Aditya Mahajan adityam@umich.edu:
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
In my case, the mode’s called "epub" and also changes a few other settings, and that’s how I stumbled upon this bug, because I had "--mode=epub" in my Makefile default.
Greetlings, Hraban --- http://www.fiee.net http://wiki.contextgarden.net GPG Key ID 1C9B22FD
On 3/3/2018 11:07 AM, Henning Hraban Ramm wrote:
Am 2018-02-27 um 16:10 schrieb Alan Braslau braslau.list@comcast.net:
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 -----------------------------------------------------------------
Am 2018-03-15 um 09:54 schrieb Hans Hagen pragma@wxs.nl:
On 3/3/2018 11:07 AM, Henning Hraban Ramm wrote:
Am 2018-02-27 um 16:10 schrieb Alan Braslau braslau.list@comcast.net:
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 nothing 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)
Thank you! I’ll check and document it.
Greetlings, Hraban --- http://www.fiee.net http://wiki.contextgarden.net GPG Key ID 1C9B22FD
-
Aditya Mahajan -
Alan Braslau -
Hans Hagen -
Henning Hraban Ramm