export breaks float p

export breaks float p

[Henning Hraban Ramm]

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

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float p

[Alan Braslau]

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
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float placement

[Henning Hraban Ramm]

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

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float placement

[Aditya Mahajan]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 435 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 492 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float placement

[Alan Braslau]

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
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float placement

[Henning Hraban Ramm]

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

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float placement

[Hans Hagen]

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
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float placement

[Henning Hraban Ramm]

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

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float placement

[Alan Braslau]

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
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float placement

[Hans Hagen]

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
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float placement

[Hans Hagen]

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
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: export breaks float placement

[Henning Hraban Ramm]

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

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________