Re: Performance regression in export to LaTeX?

[Jean-Pierre Chrétien]

Le 20/12/2021 à 12:16, Jürgen Spitzmüller a écrit :

Am Montag, dem 20.12.2021 um 10:21 +0100 schrieb Jürgen Spitzmüller:

Tried again and (once more) ended up at

commit 26ea1e14966c092a7b87c75c19b83a369e79aeb8
Author: Juergen Spitzmueller 
Date:   Sun Apr 22 19:06:46 2018 +0200

     Align fontenc with document fonts

I'll check if we can do something.


c2f2ba57f1275c should address this one.


Now :

real0m11,354s
user0m9,962s
sys 0m1,044s
--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Scott Kostyshak]

On Mon, Dec 20, 2021 at 12:41:03PM +0100, Kornel Benko wrote:
> Am Mon, 20 Dec 2021 12:08:01 +0100
> schrieb Jürgen Spitzmüller :
> 
> > Am Montag, dem 20.12.2021 um 11:19 +0100 schrieb Kornel Benko:
> > > Same commit as originally found Scott :)  
> > 
> > Which is what the "once more" part referred to.
> 
> I missed it.

Thanks for figuring it out, Jürgen and for the fix!

> > > BTW, I am surprised by your time-values. Here the export took 1m 51
> > > secs before the last
> > > commit, and now I see 57 secs for the export to pdflatex. (User time)  
> > 
> > Scott also had higher values. Seems to depend on the machine's power
> > (maybe also compile settings).
> 
> Most probably flags. Compiling with -fsanitize + debug.

Indeed, I think it is a combination of both. I hope to get a new laptop
soon. This one has several issues, most notably the I/O issue.

In addition I am using the debug flags and fsanitize on master.

> So, now, after commit c2f2ba57, the time was going down to 26.704u. Nice.

Big improvement here, also. Thanks!

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Kornel Benko]

Am Mon, 20 Dec 2021 12:08:01 +0100
schrieb Jürgen Spitzmüller :

> Am Montag, dem 20.12.2021 um 11:19 +0100 schrieb Kornel Benko:
> > Same commit as originally found Scott :)  
> 
> Which is what the "once more" part referred to.

I missed it.

> > BTW, I am surprised by your time-values. Here the export took 1m 51
> > secs before the last
> > commit, and now I see 57 secs for the export to pdflatex. (User time)  
> 
> Scott also had higher values. Seems to depend on the machine's power
> (maybe also compile settings).

Most probably flags. Compiling with -fsanitize + debug.

> Jürgen

So, now, after commit c2f2ba57, the time was going down to 26.704u. Nice.

Kornel


pgpqORwYnzUpU.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Montag, dem 20.12.2021 um 10:21 +0100 schrieb Jürgen Spitzmüller:
> Tried again and (once more) ended up at
> 
> commit 26ea1e14966c092a7b87c75c19b83a369e79aeb8
> Author: Juergen Spitzmueller 
> Date:   Sun Apr 22 19:06:46 2018 +0200
> 
>     Align fontenc with document fonts
> 
> I'll check if we can do something.

c2f2ba57f1275c should address this one.

Jürgen


signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Montag, dem 20.12.2021 um 11:19 +0100 schrieb Kornel Benko:
> Same commit as originally found Scott :)

Which is what the "once more" part referred to.

> BTW, I am surprised by your time-values. Here the export took 1m 51
> secs before the last
> commit, and now I see 57 secs for the export to pdflatex. (User time)

Scott also had higher values. Seems to depend on the machine's power
(maybe also compile settings).

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Kornel Benko]

Am Mon, 20 Dec 2021 10:21:35 +0100
schrieb Jürgen Spitzmüller :

> Am Sonntag, dem 19.12.2021 um 19:08 +0100 schrieb Jürgen Spitzmüller:
> > > I can bisect as well.  
> > 
> > I gave up.  
> 
> Tried again and (once more) ended up at
> 
> commit 26ea1e14966c092a7b87c75c19b83a369e79aeb8
> Author: Juergen Spitzmueller 
> Date:   Sun Apr 22 19:06:46 2018 +0200
> 
> Align fontenc with document fonts
> 
> I'll check if we can do something.
> 
> Jürgen
> 

Same commit as originally found Scott :)

BTW, I am surprised by your time-values. Here the export took 1m 51 secs before 
the last
commit, and now I see 57 secs for the export to pdflatex. (User time)

Kornel


pgpR6_HrF38p8.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Sonntag, dem 19.12.2021 um 19:08 +0100 schrieb Jürgen Spitzmüller:
> > I can bisect as well.
> 
> I gave up.

Tried again and (once more) ended up at

commit 26ea1e14966c092a7b87c75c19b83a369e79aeb8
Author: Juergen Spitzmueller 
Date:   Sun Apr 22 19:06:46 2018 +0200

Align fontenc with document fonts

I'll check if we can do something.

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jean-Pierre Chrétien]

Le 19/12/2021 à 15:45, Jürgen Spitzmüller a écrit :

Am Sonntag, dem 19.12.2021 um 15:03 +0100 schrieb Jürgen Spitzmüller:

So it's the cprotection checks that seem to cost time. Need to check
whether this can be optimized.


After 61b8afd893ec we're back at

real0m19,685s
user0m15,633s
sys 0m3,025s



Recompiling after 61b8afd893ec leads here to

real0m13,374s
user0m11,999s
sys 0m1,012s

instead of

real0m31,623s
user0m22,924s
sys0m1,532s

(which includes 9s of lyx reconfiguration, that means thet real must be rather 
22s).

To be compared to the 2.3.x result

real0m9,749s
user0m8,459s
sys0m1,320s

So the ratio is now 10/13 instead of a little
over 2.

--
Jean-Pierre


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Sonntag, dem 19.12.2021 um 19:21 + schrieb José Abílio Matos:
> If this proves to be a problem we can speed lyx2lyx code (using
> profiling to identify the bottlenecks).

No, this doesn't seem to be involved.

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[José Abílio Matos]

On Sunday, 19 December 2021 17.15.19 WET Jürgen Spitzmüller wrote:
> The first thing to check, since this is a 2.3.x file, is how much time
> is taken by lyx2lyx.

If this proves to be a problem we can speed lyx2lyx code (using profiling to 
identify the bottlenecks).
 
-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jean-Marc Lasgouttes]

Le 19/12/2021 à 19:22, Scott Kostyshak a écrit :

On Sun, Dec 19, 2021 at 07:08:56PM +0100, Jürgen Spitzmüller wrote:

Am Sonntag, dem 19.12.2021 um 18:15 +0100 schrieb Jürgen Spitzmüller:

I can bisect as well.


I gave up.


I'll give it a try. Might not be able to do it until tomorrow though.


If we find a really big document, we can also try to run it under a 
profiler. I am not sure whether 5 seconds of UserGuide.lyx will be 
enough. Is this with runtime debugging disables?


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Scott Kostyshak]

On Sun, Dec 19, 2021 at 07:08:56PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, dem 19.12.2021 um 18:15 +0100 schrieb Jürgen Spitzmüller:
> > I can bisect as well.
> 
> I gave up.

I'll give it a try. Might not be able to do it until tomorrow though.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Sonntag, dem 19.12.2021 um 18:15 +0100 schrieb Jürgen Spitzmüller:
> I can bisect as well.

I gave up.

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Sonntag, dem 19.12.2021 um 11:55 -0500 schrieb Scott Kostyshak:
> I can try to do another bisect if there's interest. I'm just not sure
> this is something even related to a use case. I guess the first thing
> to check would be if indeed the issue only shows up with a very long
> line.

The first thing to check, since this is a 2.3.x file, is how much time
is taken by lyx2lyx.

If I convert your example file to master file format, I get

real0m6,868s
user0m6,828s
sys 0m0,020s

So, yes, it seems worthwile to investigate.

I can bisect as well.

Jürgen


signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Scott Kostyshak]

On Sun, Dec 19, 2021 at 05:39:16PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, dem 19.12.2021 um 11:37 -0500 schrieb Scott Kostyshak:
> > Thanks for checking. Indeed I think my computer has some performance
> > issues (especially with I/O, which I think is relevant in this case).
> > 
> > And what do you get with 2.3.0?
> 
> real  0m1,108s
> user  0m1,077s
> sys   0m0,031s
> 
> So there is a significant difference here, as well.

I can try to do another bisect if there's interest. I'm just not sure
this is something even related to a use case. I guess the first thing to
check would be if indeed the issue only shows up with a very long line.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Sonntag, dem 19.12.2021 um 11:37 -0500 schrieb Scott Kostyshak:
> Thanks for checking. Indeed I think my computer has some performance
> issues (especially with I/O, which I think is relevant in this case).
> 
> And what do you get with 2.3.0?

real0m1,108s
user0m1,077s
sys 0m0,031s

So there is a significant difference here, as well.

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Scott Kostyshak]

On Sun, Dec 19, 2021 at 05:29:07PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, dem 19.12.2021 um 17:24 +0100 schrieb Jürgen Spitzmüller:
> > Though I am getting
> > 
> > real0m5,935s
> > user0m5,739s
> > sys 0m0,066s
> > 
> > With this on master (with -e pdflatex).
> 
> (i.e., with your testfile)

Thanks for checking. Indeed I think my computer has some performance
issues (especially with I/O, which I think is relevant in this case).

And what do you get with 2.3.0?

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Sonntag, dem 19.12.2021 um 17:24 +0100 schrieb Jürgen Spitzmüller:
> Though I am getting
> 
> real  0m5,935s
> user  0m5,739s
> sys   0m0,066s
> 
> With this on master (with -e pdflatex).

(i.e., with your testfile)

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Sonntag, dem 19.12.2021 um 11:10 -0500 schrieb Scott Kostyshak:
> On master (with your recent fix), I get times like the following:
> 
>   real0m44.676s
>   user0m44.575s
>   sys 0m0.092s
> 
> I'm still using the following command when testing:
> 
>   time mylyx 2.3.x -e pdflatex UserGuide.lyx
> 
> The format "pdflatex" is the shortname for "LaTeX (pdflatex)", where
> pdf2 is the shortname for "PDF (pdflatex)". i.e., I'm checking just
> LyX's LaTeX export without compiling.

You're right.

Though I am getting

real0m5,935s
user0m5,739s
sys 0m0,066s

With this on master (with -e pdflatex).

Jürgen


signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Scott Kostyshak]

On Sun, Dec 19, 2021 at 03:45:40PM +0100, Jürgen Spitzmüller wrote:
> Am Sonntag, dem 19.12.2021 um 15:03 +0100 schrieb Jürgen Spitzmüller:
> > So it's the cprotection checks that seem to cost time. Need to check
> > whether this can be optimized.
> 
> After 61b8afd893ec we're back at
> 
> real  0m19,685s
> user  0m15,633s
> sys   0m3,025s
> 
> Which is still a bit slower than stable, but a lot faster that where we
> have been.

Thank you, Jürgen! That is indeed much better.

Here is an example file that might show a different (but related?)
issue:

  https://www.dropbox.com/s/cwaj2ms14fln8oi/example.23.lyx?dl=0

It's a contrived example file. It just pastes a string like "h" over
and over. I think it is all on the same line. And pdflatex refuses to
compile it because of the extremely long line. I get:

  "! Unable to read an entire line---bufsize=20."

Thus, a fair response would be "find me a more reasonable use case
before making noise" :)

Nonetheless, the difference in timings are quite large:

On 2.3.0 I'm getting times like the following:

  real  0m6.476s
  user  0m6.396s
  sys   0m0.081s

On master (with your recent fix), I get times like the following:

  real  0m44.676s
  user  0m44.575s
  sys   0m0.092s

I'm still using the following command when testing:

  time mylyx 2.3.x -e pdflatex UserGuide.lyx

The format "pdflatex" is the shortname for "LaTeX (pdflatex)", where
pdf2 is the shortname for "PDF (pdflatex)". i.e., I'm checking just
LyX's LaTeX export without compiling.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Sonntag, dem 19.12.2021 um 15:03 +0100 schrieb Jürgen Spitzmüller:
> So it's the cprotection checks that seem to cost time. Need to check
> whether this can be optimized.

After 61b8afd893ec we're back at

real0m19,685s
user0m15,633s
sys 0m3,025s

Which is still a bit slower than stable, but a lot faster that where we
have been.

Jürgen




signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Sonntag, dem 19.12.2021 um 11:45 +0100 schrieb Jürgen Spitzmüller:
> I try to bisect myself.

This leads to:

commit b814c4fda732c8b5ee019692eb881c35b9335da6
Author: Juergen Spitzmueller 
Date:   Sun Sep 20 08:45:42 2020 +0200

Fix unnecessary cprotect

Note, however, that this is not accountable for all the increment.
There seem to be several minor leaps involved additionally. But the one
above is the most significant (by far), ca. 10 secs.

So it's the cprotection checks that seem to cost time. Need to check
whether this can be optimized.

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jürgen Spitzmüller]

Am Samstag, dem 18.12.2021 um 13:26 -0500 schrieb Scott Kostyshak:
> Thanks, Jean-Pierre. I wonder why you must export to pdf2. Using
> "pdflatex" instead gives an error?

Because -e takes a file format as argument, and the file format for
pdflatex output is pdf2, not pdflatex.

> 
> In any case, I see roughly the same ratio. I tried to do a bisect and
> got to the following:
> 
>   commit 26ea1e14966c092a7b87c75c19b83a369e79aeb8
>   Author: Juergen Spitzmueller 
>   Date:   Sun Apr 22 19:06:46 2018 +0200
>   
>   Align fontenc with document fonts
> 
> But I'm not so confident in my bisect since performance issues are
> hard to bisect. This commit also changes file format and prefs
> change, so that might play a role.

I do not see such a huge difference.

At 26ea1e14966c

real0m18,531s
user0m13,952s
sys 0m3,168s


At 337ec5830a041 (the commit before):

real0m16,335s
user0m11,609s
sys 0m3,259s

So a bit more, but not that much.

Stable gives:

real0m16,731s
user0m11,244s
sys 0m4,251s

And current master:

real0m33,165s
user0m28,740s
sys 0m3,420s

So the cuplrit must be later (or it's a cumulative increasement).

I try to bisect myself.

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Scott Kostyshak]

On Sat, Dec 18, 2021 at 12:01:36PM +0100, Jean-Pierre Chrétien wrote:
> Le 18/12/2021 à 03:23, Scott Kostyshak a écrit :
> > If I do
> > 
> >time lyx -e pdflatex UserGuide.lyx
> > 
> > I get big differences in timings if I do the above with master versus
> > with 2.3.0. I'm not sure these differences necessarily mean a
> > regression. I've definitely compiled master with different compile
> > flags.
> > 
> > Does anyone else see differences when comparing 2.3.0 (or 2.3.x) to
> > master with the above command?
> 
> Hello Scott,
> 
> Here I must run
> 
> time  -e pdf2 UserGuide.lyx
> 
> With 2.3.7dev:
> 
> real  0m9,749s
> user  0m8,459s
> sys   0m1,320s
> 
> 
> With 2.4.0dev (up to date):
> 
> real  0m31,623s
> user  0m22,924s
> sys   0m1,532s
> 
> Ration ~ 3

Thanks, Jean-Pierre. I wonder why you must export to pdf2. Using
"pdflatex" instead gives an error?

In any case, I see roughly the same ratio. I tried to do a bisect and
got to the following:

  commit 26ea1e14966c092a7b87c75c19b83a369e79aeb8
  Author: Juergen Spitzmueller 
  Date:   Sun Apr 22 19:06:46 2018 +0200
  
  Align fontenc with document fonts

But I'm not so confident in my bisect since performance issues are hard
to bisect. This commit also changes file format and prefs change, so
that might play a role.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Performance regression in export to LaTeX?

[Jean-Pierre Chrétien]

Le 18/12/2021 à 03:23, Scott Kostyshak a écrit :

If I do

   time lyx -e pdflatex UserGuide.lyx

I get big differences in timings if I do the above with master versus
with 2.3.0. I'm not sure these differences necessarily mean a
regression. I've definitely compiled master with different compile
flags.

Does anyone else see differences when comparing 2.3.0 (or 2.3.x) to
master with the above command?


Hello Scott,

Here I must run

time  -e pdf2 UserGuide.lyx

With 2.3.7dev:

real0m9,749s
user0m8,459s
sys 0m1,320s


With 2.4.0dev (up to date):

real0m31,623s
user0m22,924s
sys 0m1,532s

Ration ~ 3

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Performance regression in export to LaTeX?

[Scott Kostyshak]

If I do

  time lyx -e pdflatex UserGuide.lyx

I get big differences in timings if I do the above with master versus
with 2.3.0. I'm not sure these differences necessarily mean a
regression. I've definitely compiled master with different compile
flags.

Does anyone else see differences when comparing 2.3.0 (or 2.3.x) to
master with the above command?

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Math.lyx export to latex

[Guenter Milde]

On 2015-03-31, Kornel Benko wrote:


 What is a good name for the subdir? 

Similar to the behaviour of web browsers when downloading HTML+images, I'd
name it document-name-without-extension-files/ i.e. for math.tex it
would becomd math-files/


 What do we do if it already exists?

Add a number or ask.

Günter

Re: Math.lyx export to latex

[Scott Kostyshak]

On Wed, Apr 1, 2015 at 4:56 PM, Georg Baum
georg.b...@post.rwth-aachen.de wrote:
 Guenter Milde wrote:

 On 2015-03-31, Kornel Benko wrote:


 What is a good name for the subdir?

 Similar to the behaviour of web browsers when downloading HTML+images, I'd
 name it document-name-without-extension-files/ i.e. for math.tex it
 would becomd math-files/

 This looks good.

 I have a vague memory that image output to a directory is already
 implemented, but I could not find it. I guess my memory is wrong.

Are you thinking of our export to LyX Archive (lyxpak.py) ?

Scott

Re: Math.lyx export to latex

[Georg Baum]

Guenter Milde wrote:

 On 2015-03-31, Kornel Benko wrote:
 
 
 What is a good name for the subdir?
 
 Similar to the behaviour of web browsers when downloading HTML+images, I'd
 name it document-name-without-extension-files/ i.e. for math.tex it
 would becomd math-files/

This looks good.

I have a vague memory that image output to a directory is already 
implemented, but I could not find it. I guess my memory is wrong.

 What do we do if it already exists?
 
 Add a number or ask.

For automated documentation builds it is important that the behaviour is 
predictable, and only influenced by document settings, not by properties of 
the file system (if it is full, a network directory is currently 
unavailable, or file permissions changed, then this needs to result in an 
error, not in an alternative export location). IMHO the fact that the 
directory does already exist does not mean anything. The most probable 
reason for this is that the current LaTeX export is not the first one that 
the user did from this document. Asking would be consistent with what is 
done already for the main document, adding a number is not really wanted, 
since several exports in a row would produce several numbered directories.

IMHO the crucial questions is how the export to a directory should be 
controlled. Currently I believe the best way to do it is like inkscape does 
it, but maybe somebody has a better idea? Inkscape saves the name of the 
exported file in the document, and if the export is repeated this name is 
used without asking again. Similarly, LyX could have the export directory as 
a document setting (relative or absolute, like for included files). If it is 
empty, the export would be done to the original locations like it is now. If 
it is not empty, the given directory would be used. One should also add some 
convenience and if the directory is empty, but some export failed, ask 
whether an export directory should be created, with the name given above. 
This question would then only be asked for the very first export, and 
subsequent exports would all use the same directory.

Such an implementation is both predictable and controllable enough for 
automatic builds, but also convenient enough for interactive usage of 
possibly inexperienced users.


Georg

Re: Math.lyx export to latex

[Guenter Milde]

On 2015-03-31, Kornel Benko wrote:


> What is a good name for the subdir? 

Similar to the behaviour of web browsers when downloading HTML+images, I'd
name it "-files/" i.e. for "math.tex" it
would becomd "math-files/"


> What do we do if it already exists?

Add a number or ask.

Günter

Re: Math.lyx export to latex

[Georg Baum]

Guenter Milde wrote:

> On 2015-03-31, Kornel Benko wrote:
> 
> 
>> What is a good name for the subdir?
> 
> Similar to the behaviour of web browsers when downloading HTML+images, I'd
> name it "-files/" i.e. for "math.tex" it
> would becomd "math-files/"

This looks good.

I have a vague memory that image output to a directory is already 
implemented, but I could not find it. I guess my memory is wrong.

>> What do we do if it already exists?
> 
> Add a number or ask.

For automated documentation builds it is important that the behaviour is 
predictable, and only influenced by document settings, not by properties of 
the file system (if it is full, a network directory is currently 
unavailable, or file permissions changed, then this needs to result in an 
error, not in an alternative export location). IMHO the fact that the 
directory does already exist does not mean anything. The most probable 
reason for this is that the current LaTeX export is not the first one that 
the user did from this document. Asking would be consistent with what is 
done already for the main document, adding a number is not really wanted, 
since several exports in a row would produce several numbered directories.

IMHO the crucial questions is how the export to a directory should be 
controlled. Currently I believe the best way to do it is like inkscape does 
it, but maybe somebody has a better idea? Inkscape saves the name of the 
exported file in the document, and if the export is repeated this name is 
used without asking again. Similarly, LyX could have the export directory as 
a document setting (relative or absolute, like for included files). If it is 
empty, the export would be done to the original locations like it is now. If 
it is not empty, the given directory would be used. One should also add some 
convenience and if the directory is empty, but some export failed, ask 
whether an export directory should be created, with the name given above. 
This question would then only be asked for the very first export, and 
subsequent exports would all use the same directory.

Such an implementation is both predictable and controllable enough for 
automatic builds, but also convenient enough for interactive usage of 
possibly inexperienced users.


Georg

Re: Math.lyx export to latex

[Scott Kostyshak]

On Wed, Apr 1, 2015 at 4:56 PM, Georg Baum
 wrote:
> Guenter Milde wrote:
>
>> On 2015-03-31, Kornel Benko wrote:
>>
>>
>>> What is a good name for the subdir?
>>
>> Similar to the behaviour of web browsers when downloading HTML+images, I'd
>> name it "-files/" i.e. for "math.tex" it
>> would becomd "math-files/"
>
> This looks good.
>
> I have a vague memory that image output to a directory is already
> implemented, but I could not find it. I guess my memory is wrong.

Are you thinking of our export to LyX Archive ("lyxpak.py") ?

Scott

Re: Math.lyx export to latex

[Kornel Benko]

Am Montag, 30. März 2015 um 20:26:04, schrieb Scott Kostyshak skost...@lyx.org
 On Mon, Mar 30, 2015 at 8:12 PM, Enrico Forestieri for...@lyx.org wrote:
  On Sun, Mar 29, 2015 at 11:07:35PM +0200, Kornel Benko wrote:
 
  This is a recipe to observe creation of files in lyx-source
 
  1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say 
  ~/lyx/test/.
This is not needed, but shows that the behaviour does not depend on
the path of Math.lyx
  2.) use your lyx from the build directory to open the file
  3.) File-Export-LaTeX(LuaLaTeX)
 
  Now go to the lyx-source
  # git status
 
  You see many untracked .pdf files like e.g. 
  lib/images/math-macro-remove-greedy-param.pdf
 
  I think this is the expected behavior. When you export to latex, in order
  to ensure compilation, all images gets converted to a format that latex
  understands. If you reference a svg image and export to pdflatex, this
  image has to be converted. On the other hand, if you reference a png image
  no conversion is needed, because pdflatex can deal with pngs.
 
  Note that it means nothing that you saved elsewhere the document, because
  full paths are still used to point to the original images (that are not
  moved alongside the document, or that are always found in the lyx 
  installation
  directory for the icon info inset). Also note that the icon info inset is
  simply equivalent to the graphics inset.
 
  This is nothing new, I think, and you should have got the same result if
  you tried exporting to plain latex in the case of png icons, because in
  this case all pngs should be converted to postscript. However, nobody
  seems producing dvi or postscript output for the lyx documentation and
  thus this was going unnoticed when the icons were in png format.
 
  This only occurs if you first export to latex, but of course you can always
  produce output directly from lyx, because in this case all images are
  copied to the temporary directory.
 
  In conclusion, if your document references an image located in a directory
  where you have no writing rights, you cannot export your document to latex
  without incurring in those shortcomings. Nothing new.
 
 Thank you for this clear explanation of what's going on.

 It seems there is an enhancement that we can do. For example, we could
 have a user-friendly dialog about not having write permissions to the
 directory where an image is stored. The only alternative I can think
 of is to change the path of the image to the same directory where the
 .tex file is exported to.

+1 to the alternative. Why pollute the the source dirs of the icons?

 Scott

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Enrico Forestieri]

On Tue, Mar 31, 2015 at 09:04:41AM +0200, Kornel Benko wrote:
 Am Montag, 30. März 2015 um 20:26:04, schrieb Scott Kostyshak 
 skost...@lyx.org
 
  It seems there is an enhancement that we can do. For example, we could
  have a user-friendly dialog about not having write permissions to the
  directory where an image is stored. The only alternative I can think
  of is to change the path of the image to the same directory where the
  .tex file is exported to.
 
 +1 to the alternative. Why pollute the the source dirs of the icons?

What about the fact that an image with same name already exists there?
As it is not alongside the source image, it is possible that it is
not related. In the case of latex exports, the only sensible thing
is copying to a properly named subdir the images and all necessary
files not already in the document dir or a subdir of it, IMO.

-- 
Enrico

Re: Math.lyx export to latex

[Kornel Benko]

Am Dienstag, 31. März 2015 um 11:02:45, schrieb Enrico Forestieri 
for...@lyx.org
 On Tue, Mar 31, 2015 at 09:04:41AM +0200, Kornel Benko wrote:
  Am Montag, 30. März 2015 um 20:26:04, schrieb Scott Kostyshak 
  skost...@lyx.org
  
   It seems there is an enhancement that we can do. For example, we could
   have a user-friendly dialog about not having write permissions to the
   directory where an image is stored. The only alternative I can think
   of is to change the path of the image to the same directory where the
   .tex file is exported to.
  
  +1 to the alternative. Why pollute the the source dirs of the icons?
 
 What about the fact that an image with same name already exists there?
 As it is not alongside the source image, it is possible that it is
 not related. In the case of latex exports, the only sensible thing
 is copying to a properly named subdir the images and all necessary
 files not already in the document dir or a subdir of it, IMO.

Document subdir is fine with me. Especially good, if 'exporting as', so 
everything needed
is there too.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Scott Kostyshak]

On Tue, Mar 31, 2015 at 5:36 AM, Kornel Benko kor...@lyx.org wrote:
 Am Dienstag, 31. März 2015 um 11:02:45, schrieb Enrico Forestieri 
 for...@lyx.org
 On Tue, Mar 31, 2015 at 09:04:41AM +0200, Kornel Benko wrote:
  Am Montag, 30. März 2015 um 20:26:04, schrieb Scott Kostyshak 
  skost...@lyx.org
 
   It seems there is an enhancement that we can do. For example, we could
   have a user-friendly dialog about not having write permissions to the
   directory where an image is stored. The only alternative I can think
   of is to change the path of the image to the same directory where the
   .tex file is exported to.
 
  +1 to the alternative. Why pollute the the source dirs of the icons?

 What about the fact that an image with same name already exists there?
 As it is not alongside the source image, it is possible that it is
 not related. In the case of latex exports, the only sensible thing
 is copying to a properly named subdir the images and all necessary
 files not already in the document dir or a subdir of it, IMO.

 Document subdir is fine with me. Especially good, if 'exporting as', so 
 everything needed
 is there too.

Sounds good. Would we only do this if the other directory does not
have write permissions? Or to be consistent we would always do it?

What is a good name for the subdir? What do we do if it already exists?

Scott

Re: Math.lyx export to latex

[Kornel Benko]

Am Dienstag, 31. März 2015 um 10:31:18, schrieb Scott Kostyshak 
skost...@lyx.org
 On Tue, Mar 31, 2015 at 5:36 AM, Kornel Benko kor...@lyx.org wrote:
  Am Dienstag, 31. März 2015 um 11:02:45, schrieb Enrico Forestieri 
  for...@lyx.org
  On Tue, Mar 31, 2015 at 09:04:41AM +0200, Kornel Benko wrote:
   Am Montag, 30. März 2015 um 20:26:04, schrieb Scott Kostyshak 
   skost...@lyx.org
  
It seems there is an enhancement that we can do. For example, we could
have a user-friendly dialog about not having write permissions to the
directory where an image is stored. The only alternative I can think
of is to change the path of the image to the same directory where the
.tex file is exported to.
  
   +1 to the alternative. Why pollute the the source dirs of the icons?
 
  What about the fact that an image with same name already exists there?
  As it is not alongside the source image, it is possible that it is
  not related. In the case of latex exports, the only sensible thing
  is copying to a properly named subdir the images and all necessary
  files not already in the document dir or a subdir of it, IMO.
 
  Document subdir is fine with me. Especially good, if 'exporting as', so 
  everything needed
  is there too.
 
 Sounds good. Would we only do this if the other directory does not
 have write permissions? Or to be consistent we would always do it?

I'd plead for always.

 What is a good name for the subdir? What do we do if it already exists?

What about e.g for exported Math.tex the subdir name 'Math.tex.subdir'

 Scott

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Kornel Benko]

Am Montag, 30. März 2015 um 20:26:04, schrieb Scott Kostyshak <skost...@lyx.org>
> On Mon, Mar 30, 2015 at 8:12 PM, Enrico Forestieri <for...@lyx.org> wrote:
> > On Sun, Mar 29, 2015 at 11:07:35PM +0200, Kornel Benko wrote:
> >
> >> This is a recipe to observe creation of files in lyx-source
> >>
> >> 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say 
> >> ~/lyx/test/.
> >>   This is not needed, but shows that the behaviour does not depend on
> >>   the path of Math.lyx
> >> 2.) use your lyx from the build directory to open the file
> >> 3.) File->Export->LaTeX(LuaLaTeX)
> >>
> >> Now go to the lyx-source
> >> # git status
> >>
> >> You see many untracked .pdf files like e.g. 
> >> lib/images/math-macro-remove-greedy-param.pdf
> >
> > I think this is the expected behavior. When you export to latex, in order
> > to ensure compilation, all images gets converted to a format that latex
> > understands. If you reference a svg image and export to pdflatex, this
> > image has to be converted. On the other hand, if you reference a png image
> > no conversion is needed, because pdflatex can deal with pngs.
> >
> > Note that it means nothing that you saved elsewhere the document, because
> > full paths are still used to point to the original images (that are not
> > moved alongside the document, or that are always found in the lyx 
> > installation
> > directory for the icon info inset). Also note that the icon info inset is
> > simply equivalent to the graphics inset.
> >
> > This is nothing new, I think, and you should have got the same result if
> > you tried exporting to plain latex in the case of png icons, because in
> > this case all pngs should be converted to postscript. However, nobody
> > seems producing dvi or postscript output for the lyx documentation and
> > thus this was going unnoticed when the icons were in png format.
> >
> > This only occurs if you first export to latex, but of course you can always
> > produce output directly from lyx, because in this case all images are
> > copied to the temporary directory.
> >
> > In conclusion, if your document references an image located in a directory
> > where you have no writing rights, you cannot export your document to latex
> > without incurring in those shortcomings. Nothing new.
> 
> Thank you for this clear explanation of what's going on.

> It seems there is an enhancement that we can do. For example, we could
> have a user-friendly dialog about not having write permissions to the
> directory where an image is stored. The only alternative I can think
> of is to change the path of the image to the same directory where the
> .tex file is exported to.

+1 to the alternative. Why pollute the the source dirs of the icons?

> Scott

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Enrico Forestieri]

On Tue, Mar 31, 2015 at 09:04:41AM +0200, Kornel Benko wrote:
> Am Montag, 30. März 2015 um 20:26:04, schrieb Scott Kostyshak 
> 
> 
> > It seems there is an enhancement that we can do. For example, we could
> > have a user-friendly dialog about not having write permissions to the
> > directory where an image is stored. The only alternative I can think
> > of is to change the path of the image to the same directory where the
> > .tex file is exported to.
> 
> +1 to the alternative. Why pollute the the source dirs of the icons?

What about the fact that an image with same name already exists there?
As it is not alongside the source image, it is possible that it is
not related. In the case of latex exports, the only sensible thing
is copying to a properly named subdir the images and all necessary
files not already in the document dir or a subdir of it, IMO.

-- 
Enrico

Re: Math.lyx export to latex

[Kornel Benko]

Am Dienstag, 31. März 2015 um 11:02:45, schrieb Enrico Forestieri 

> On Tue, Mar 31, 2015 at 09:04:41AM +0200, Kornel Benko wrote:
> > Am Montag, 30. März 2015 um 20:26:04, schrieb Scott Kostyshak 
> > 
> > 
> > > It seems there is an enhancement that we can do. For example, we could
> > > have a user-friendly dialog about not having write permissions to the
> > > directory where an image is stored. The only alternative I can think
> > > of is to change the path of the image to the same directory where the
> > > .tex file is exported to.
> > 
> > +1 to the alternative. Why pollute the the source dirs of the icons?
> 
> What about the fact that an image with same name already exists there?
> As it is not alongside the source image, it is possible that it is
> not related. In the case of latex exports, the only sensible thing
> is copying to a properly named subdir the images and all necessary
> files not already in the document dir or a subdir of it, IMO.

Document subdir is fine with me. Especially good, if 'exporting as', so 
everything needed
is there too.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Scott Kostyshak]

On Tue, Mar 31, 2015 at 5:36 AM, Kornel Benko  wrote:
> Am Dienstag, 31. März 2015 um 11:02:45, schrieb Enrico Forestieri 
> 
>> On Tue, Mar 31, 2015 at 09:04:41AM +0200, Kornel Benko wrote:
>> > Am Montag, 30. März 2015 um 20:26:04, schrieb Scott Kostyshak 
>> > 
>> >
>> > > It seems there is an enhancement that we can do. For example, we could
>> > > have a user-friendly dialog about not having write permissions to the
>> > > directory where an image is stored. The only alternative I can think
>> > > of is to change the path of the image to the same directory where the
>> > > .tex file is exported to.
>> >
>> > +1 to the alternative. Why pollute the the source dirs of the icons?
>>
>> What about the fact that an image with same name already exists there?
>> As it is not alongside the source image, it is possible that it is
>> not related. In the case of latex exports, the only sensible thing
>> is copying to a properly named subdir the images and all necessary
>> files not already in the document dir or a subdir of it, IMO.
>
> Document subdir is fine with me. Especially good, if 'exporting as', so 
> everything needed
> is there too.

Sounds good. Would we only do this if the other directory does not
have write permissions? Or to be consistent we would always do it?

What is a good name for the subdir? What do we do if it already exists?

Scott

Re: Math.lyx export to latex

[Kornel Benko]

Am Dienstag, 31. März 2015 um 10:31:18, schrieb Scott Kostyshak 

> On Tue, Mar 31, 2015 at 5:36 AM, Kornel Benko  wrote:
> > Am Dienstag, 31. März 2015 um 11:02:45, schrieb Enrico Forestieri 
> > 
> >> On Tue, Mar 31, 2015 at 09:04:41AM +0200, Kornel Benko wrote:
> >> > Am Montag, 30. März 2015 um 20:26:04, schrieb Scott Kostyshak 
> >> > 
> >> >
> >> > > It seems there is an enhancement that we can do. For example, we could
> >> > > have a user-friendly dialog about not having write permissions to the
> >> > > directory where an image is stored. The only alternative I can think
> >> > > of is to change the path of the image to the same directory where the
> >> > > .tex file is exported to.
> >> >
> >> > +1 to the alternative. Why pollute the the source dirs of the icons?
> >>
> >> What about the fact that an image with same name already exists there?
> >> As it is not alongside the source image, it is possible that it is
> >> not related. In the case of latex exports, the only sensible thing
> >> is copying to a properly named subdir the images and all necessary
> >> files not already in the document dir or a subdir of it, IMO.
> >
> > Document subdir is fine with me. Especially good, if 'exporting as', so 
> > everything needed
> > is there too.
> 
> Sounds good. Would we only do this if the other directory does not
> have write permissions? Or to be consistent we would always do it?

I'd plead for always.

> What is a good name for the subdir? What do we do if it already exists?

What about e.g for exported Math.tex the subdir name 'Math.tex.subdir'

> Scott

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Kornel Benko]

I tried to debug, but ended at /usr/src/lyx/lyx-git/src/Exporter.cpp:142
FileMap::const_iterator cit = externalfiles_.find(format);

Here the log:
gdb) b FileName.cpp:690
Breakpoint 1, lyx::support::FileName::createPath (this=0x7fffe3ffe910) at 
/usr/src/lyx/lyx-git/src/support/FileName.cpp:690
690 LYXERR(Debug::FILES, creating path '  *this  '.);
(gdb) up
#1  0x00c8d270 in lyx::Buffer::doExport (this=0x218a730, target=..., 
put_in_tempdir=false, includeall=false, result_file=...) at 
/usr/src/lyx/lyx-git/src/Buffer.cpp:4154
4154fixedFileName.onlyPath().createPath();
...
(gdb) p fixedName
$4 = {
  static npos = optimized out,
  _M_dataplus = {
std::allocatorchar = {
  __gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
members of std::basic_stringchar, std::char_traitschar, 
std::allocatorchar ::_Alloc_hider:
_M_p = 0x7fffdc0e5538 /usr/src/lyx/lyx-git/lib/images/math-mode.pdf
  }
}
(gdb) p dest
$2 = {
  static npos = optimized out,
  _M_dataplus = {
std::allocatorchar = {
  __gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
members of std::basic_stringchar, std::char_traitschar, 
std::allocatorchar ::_Alloc_hider:
_M_p = 0x7fffdc0f6688 /home/kornel/lyx/test/
  }
}
(gdb) p it-exportName
$5 = {
  static npos = optimized out,
  _M_dataplus = {
std::allocatorchar = {
  __gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
members of std::basic_stringchar, std::char_traitschar, 
std::allocatorchar ::_Alloc_hider:
_M_p = 0x7fffdc0e5538 /usr/src/lyx/lyx-git/lib/images/math-mode.pdf
  }
}
(gdb) p format
$7 = {
  static npos = optimized out,
  _M_dataplus = {
std::allocatorchar = {
  __gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
members of std::basic_stringchar, std::char_traitschar, 
std::allocatorchar ::_Alloc_hider:
_M_p = 0x2f955f8 luatex
  }
}
(gdb) p fmt
$8 = {
  static npos = optimized out,
  _M_dataplus = {
std::allocatorchar = {
  __gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
members of std::basic_stringchar, std::char_traitschar, 
std::allocatorchar ::_Alloc_hider:
_M_p = 0x7fffdc0fcc18 pdf6
  }
}
...

What I do not understand, why it-exportName references (incorrectly in my 
eyes) /usr/src/lyx/lyx-git/lib/images/math-mode.pdf
although dest is set to /home/kornel/lyx/test/. (This is the dir where Math.lyx 
lies)

Next try was to stop at Buffer.cpp:4134 (vectorExportedFile const files = ...)
only to stop at above mentioned Exporter.cpp.

Please help.

Kornel

Am Montag, 30. März 2015 um 11:26:23, schrieb Kornel Benko kor...@lyx.org
 Am Sonntag, 29. März 2015 um 23:07:35, schrieb Kornel Benko kor...@lyx.org
  This is a recipe to observe creation of files in lyx-source
  
  1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say 
  ~/lyx/test/.
  This is not needed, but shows that the behaviour does not depend on
  the path of Math.lyx
  2.) use your lyx from the build directory to open the file
  3.) File-Export-LaTeX(LuaLaTeX)
  
  Now go to the lyx-source
  # git status
  
  You see many untracked .pdf files like e.g. 
  lib/images/math-macro-remove-greedy-param.pdf
  
  Second scenario with installed lyx. Make sure, the lyx system dirs are not 
  writeable by you
  
  2.) open the file
  3.) try the export.
  Now you are facing a dialog saying some file could not be copied.
  Click OK.
  Next dialog pops up.
  This goes on for 43 files.
  
 
 Apparently nobody seems interested.
 
 I tried to hunt it down with strace. For each created pdf file there is about 
 3000 lines trace.
 Too big to send, but some interesting lines are there, like
   8951  open(/usr/src/lyx/lyx-git/lib/images/qt_temp.wv8939, 
 O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 12
   ...
   8951  rename(/usr/src/lyx/lyx-git/lib/images/qt_temp.wv8939, 
 /usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf) =  0
   ...
   8951  
 chmod(/usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf,
  0600) = 0
 
 Looks like use of qt temporary files in lyx source.
 
 OK, try to call lyx -dbg files, to hunt the messages in 
 src/support/{TempFile,FileName,filetools}.cpp .
 so here it is:
   support/FileName.cpp (690): creating path 
 '/usr/src/lyx/lyx-git/lib/images'.
   support/FileName.cpp (590): Checksumming 
 /tmp/lyx_tmpdir.jloUpnFT9257/lyx_tmpbuf0/42_usr_src_lyx_lyx-git_lib_images_math-macro-add-greedy-optional-param.pdf
  2022594892 lasted 1 ms.
   support/FileName.cpp (230): Copying 
 /usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf keep 
 symlink: 0
   support/FileName.cpp (590): Checksumming 
 /tmp/lyx_tmpdir.jloUpnFT9257/lyx_tmpbuf0/Math.tex 3063457583 lasted 14 ms.
 
   Kornel
   

signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Kornel Benko]

Am Sonntag, 29. März 2015 um 23:07:35, schrieb Kornel Benko kor...@lyx.org
 This is a recipe to observe creation of files in lyx-source
 
 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say ~/lyx/test/.
   This is not needed, but shows that the behaviour does not depend on
   the path of Math.lyx
 2.) use your lyx from the build directory to open the file
 3.) File-Export-LaTeX(LuaLaTeX)
 
 Now go to the lyx-source
 # git status
 
 You see many untracked .pdf files like e.g. 
 lib/images/math-macro-remove-greedy-param.pdf
 
 Second scenario with installed lyx. Make sure, the lyx system dirs are not 
 writeable by you
 
 2.) open the file
 3.) try the export.
   Now you are facing a dialog saying some file could not be copied.
   Click OK.
   Next dialog pops up.
   This goes on for 43 files.
 

Apparently nobody seems interested.

I tried to hunt it down with strace. For each created pdf file there is about 
3000 lines trace.
Too big to send, but some interesting lines are there, like
8951  open(/usr/src/lyx/lyx-git/lib/images/qt_temp.wv8939, 
O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 12
...
8951  rename(/usr/src/lyx/lyx-git/lib/images/qt_temp.wv8939, 
/usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf) = 0
...
8951  
chmod(/usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf,
 0600) = 0

Looks like use of qt temporary files in lyx source.

OK, try to call lyx -dbg files, to hunt the messages in 
src/support/{TempFile,FileName,filetools}.cpp .
so here it is:
support/FileName.cpp (690): creating path 
'/usr/src/lyx/lyx-git/lib/images'.
support/FileName.cpp (590): Checksumming 
/tmp/lyx_tmpdir.jloUpnFT9257/lyx_tmpbuf0/42_usr_src_lyx_lyx-git_lib_images_math-macro-add-greedy-optional-param.pdf
 2022594892 lasted 1 ms.
support/FileName.cpp (230): Copying 
/usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf keep 
symlink: 0
support/FileName.cpp (590): Checksumming 
/tmp/lyx_tmpdir.jloUpnFT9257/lyx_tmpbuf0/Math.tex 3063457583 lasted 14 ms.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Georg Baum]

Kornel Benko wrote:

 This is a recipe to observe creation of files in lyx-source
 
 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say
 ~/lyx/test/. This is not needed, but shows that the behaviour does not
 depend on the path of Math.lyx
 2.) use your lyx from the build directory to open the file
 3.) File-Export-LaTeX(LuaLaTeX)
 
 Now go to the lyx-source
 # git status
 
 You see many untracked .pdf files like e.g.
 lib/images/math-macro-remove-greedy-param.pdf

Are you sure that the correct file is opened? Maybe some black magic for 
special handling of our own docs goes havoc here? Or is is source control? I 
would expect the creation of those files if Math.lyx in the git source tree 
is opened (for LaTeX export we generate a document that can be processed by 
LaTeX, so we need to convert all included files that need conversion).

 Second scenario with installed lyx. Make sure, the lyx system dirs are not
 writeable by you
 
 2.) open the file
 3.) try the export.
 Now you are facing a dialog saying some file could not be copied.

This looks again as if the file from the installation was opened.

 Click OK.
 Next dialog pops up.
 This goes on for 43 files.

The dialog should have a don't show me again button. If this is not the case 
please file a bug.

Unfortunately I don't have time to investigate now, but I'd guess that 
neither Exporter.cpp nor TempFile is the culprit. It is normal for the 
conversion process to use temporary files. The path of the temp file looks 
wrong (it should not be in the source tree), but this is probably an 
independent problem. Also, Exporter.cpp is probably simply fed with the 
wrong names.

I'd first check all places were the buffer file name is set and the buffer 
opening. If this is correct then I'd examine the info inset, maybe it 
creates some intermediate files at the wrong place.


Georg

Re: Math.lyx export to latex

[Georg Baum]

Kornel Benko wrote:

 Am Montag, 30. März 2015 um 22:23:38, schrieb Georg Baum
 georg.b...@post.rwth-aachen.de
 Unfortunately I don't have time to investigate now, but I'd guess that
 neither Exporter.cpp nor TempFile is the culprit. It is normal for the
 conversion process to use temporary files. The path of the temp file
 looks wrong (it should not be in the source tree), but this is probably
 an independent problem. Also, Exporter.cpp is probably simply fed with
 the wrong names.
 
 I'd first check all places were the buffer file name is set and the
 buffer opening. If this is correct then I'd examine the info inset, maybe
 it creates some intermediate files at the wrong place.
 
 I tried and failed.

Since you verified that the opened .lyx file is the correct one the info 
inset becomes the most likely candidate. I had a quick look through the 
sources and there are two possible problems:

1) The temporary QImage which is created (line 423). It is easy to check 
whether this is the reason, since the QImage is not created for commandline 
export. Does the problem also occur for commandline export?

2) The temporary graphics inset which is created (line 429). The creation 
looks OK, but maybe the graphics inset has a bug. I'd continue the search 
there if the commandline export produces the files as well.


Georg

Re: Math.lyx export to latex

[Kornel Benko]

Am Montag, 30. März 2015 um 22:52:20, schrieb Georg Baum 
georg.b...@post.rwth-aachen.de
 Kornel Benko wrote:
 
  Am Montag, 30. März 2015 um 22:23:38, schrieb Georg Baum
  georg.b...@post.rwth-aachen.de
  Unfortunately I don't have time to investigate now, but I'd guess that
  neither Exporter.cpp nor TempFile is the culprit. It is normal for the
  conversion process to use temporary files. The path of the temp file
  looks wrong (it should not be in the source tree), but this is probably
  an independent problem. Also, Exporter.cpp is probably simply fed with
  the wrong names.
  
  I'd first check all places were the buffer file name is set and the
  buffer opening. If this is correct then I'd examine the info inset, maybe
  it creates some intermediate files at the wrong place.
  
  I tried and failed.
 
 Since you verified that the opened .lyx file is the correct one the info 
 inset becomes the most likely candidate. I had a quick look through the 
 sources and there are two possible problems:
 
 1) The temporary QImage which is created (line 423). It is easy to check 
 whether this is the reason, since the QImage is not created for commandline 
 export. Does the problem also occur for commandline export?

Yes, but is not visible on installed directories. There is no dialog and the 
exported
file Math.tex is OK. (As is also from the GUI, only with 43 dialogs to click to 
OK)

Exporting with lyx from the build-dir creates the pfd files in lyx source.
# cd buil-dir
# ./bin/lyx2.2 -e luatex ~/lyx/test/Math.lyx
# cd source-dir
# git status | grep pdf | wc
 19  19 517

If I set for the oxygen user interface I get
# git status | grep pdf | wc
50  501898

 2) The temporary graphics inset which is created (line 429). The creation 
 looks OK, but maybe the graphics inset has a bug. I'd continue the search 
 there if the commandline export produces the files as well.

Thanks

 Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Kornel Benko]

Am Montag, 30. März 2015 um 22:23:38, schrieb Georg Baum 
georg.b...@post.rwth-aachen.de
 Kornel Benko wrote:

  This is a recipe to observe creation of files in lyx-source
 
  1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say
  ~/lyx/test/. This is not needed, but shows that the behaviour does not
  depend on the path of Math.lyx
  2.) use your lyx from the build directory to open the file
  3.) File-Export-LaTeX(LuaLaTeX)
 
  Now go to the lyx-source
  # git status
 
  You see many untracked .pdf files like e.g.
  lib/images/math-macro-remove-greedy-param.pdf

 Are you sure that the correct file is opened?

Yes, I am sure.

 Maybe some black magic for
 special handling of our own docs goes havoc here?

No, it is direct copy of lib/doc/Math.lyx.

 Or is is source control?

I checked, clean source, clean build.

 I
 would expect the creation of those files if Math.lyx in the git source tree
 is opened (for LaTeX export we generate a document that can be processed by
 LaTeX, so we need to convert all included files that need conversion).

Yes, therefore I copied first to eliminate this possibility.

  Second scenario with installed lyx. Make sure, the lyx system dirs are not
  writeable by you

That is the case. If I make them writeable, there is no problem with export any 
more.
But of course, there are many new .pdf files there.

  2.) open the file
  3.) try the export.
  Now you are facing a dialog saying some file could not be copied.

 This looks again as if the file from the installation was opened.

It is not.

  Click OK.
  Next dialog pops up.
  This goes on for 43 files.

 The dialog should have a don't show me again button. If this is not the case
 please file a bug.

No such button. See attached (the first dialog).

 Unfortunately I don't have time to investigate now, but I'd guess that
 neither Exporter.cpp nor TempFile is the culprit. It is normal for the
 conversion process to use temporary files. The path of the temp file looks
 wrong (it should not be in the source tree), but this is probably an
 independent problem. Also, Exporter.cpp is probably simply fed with the
 wrong names.

 I'd first check all places were the buffer file name is set and the buffer
 opening. If this is correct then I'd examine the info inset, maybe it
 creates some intermediate files at the wrong place.

I tried and failed.

 Georg

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Enrico Forestieri]

On Sun, Mar 29, 2015 at 11:07:35PM +0200, Kornel Benko wrote:

 This is a recipe to observe creation of files in lyx-source
 
 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say ~/lyx/test/.
   This is not needed, but shows that the behaviour does not depend on
   the path of Math.lyx
 2.) use your lyx from the build directory to open the file
 3.) File-Export-LaTeX(LuaLaTeX)
 
 Now go to the lyx-source
 # git status
 
 You see many untracked .pdf files like e.g. 
 lib/images/math-macro-remove-greedy-param.pdf

I think this is the expected behavior. When you export to latex, in order
to ensure compilation, all images gets converted to a format that latex
understands. If you reference a svg image and export to pdflatex, this
image has to be converted. On the other hand, if you reference a png image
no conversion is needed, because pdflatex can deal with pngs.

Note that it means nothing that you saved elsewhere the document, because
full paths are still used to point to the original images (that are not
moved alongside the document, or that are always found in the lyx installation
directory for the icon info inset). Also note that the icon info inset is
simply equivalent to the graphics inset.

This is nothing new, I think, and you should have got the same result if
you tried exporting to plain latex in the case of png icons, because in
this case all pngs should be converted to postscript. However, nobody
seems producing dvi or postscript output for the lyx documentation and
thus this was going unnoticed when the icons were in png format.

This only occurs if you first export to latex, but of course you can always
produce output directly from lyx, because in this case all images are
copied to the temporary directory.

In conclusion, if your document references an image located in a directory
where you have no writing rights, you cannot export your document to latex
without incurring in those shortcomings. Nothing new.

 Second scenario with installed lyx. Make sure, the lyx system dirs are not 
 writeable by you
 
 2.) open the file
 3.) try the export.
   Now you are facing a dialog saying some file could not be copied.
   Click OK.
   Next dialog pops up.
   This goes on for 43 files.

Of course, this is also expected.

-- 
Enrico

Re: Math.lyx export to latex

[Scott Kostyshak]

On Mon, Mar 30, 2015 at 8:12 PM, Enrico Forestieri for...@lyx.org wrote:
 On Sun, Mar 29, 2015 at 11:07:35PM +0200, Kornel Benko wrote:

 This is a recipe to observe creation of files in lyx-source

 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say ~/lyx/test/.
   This is not needed, but shows that the behaviour does not depend on
   the path of Math.lyx
 2.) use your lyx from the build directory to open the file
 3.) File-Export-LaTeX(LuaLaTeX)

 Now go to the lyx-source
 # git status

 You see many untracked .pdf files like e.g. 
 lib/images/math-macro-remove-greedy-param.pdf

 I think this is the expected behavior. When you export to latex, in order
 to ensure compilation, all images gets converted to a format that latex
 understands. If you reference a svg image and export to pdflatex, this
 image has to be converted. On the other hand, if you reference a png image
 no conversion is needed, because pdflatex can deal with pngs.

 Note that it means nothing that you saved elsewhere the document, because
 full paths are still used to point to the original images (that are not
 moved alongside the document, or that are always found in the lyx installation
 directory for the icon info inset). Also note that the icon info inset is
 simply equivalent to the graphics inset.

 This is nothing new, I think, and you should have got the same result if
 you tried exporting to plain latex in the case of png icons, because in
 this case all pngs should be converted to postscript. However, nobody
 seems producing dvi or postscript output for the lyx documentation and
 thus this was going unnoticed when the icons were in png format.

 This only occurs if you first export to latex, but of course you can always
 produce output directly from lyx, because in this case all images are
 copied to the temporary directory.

 In conclusion, if your document references an image located in a directory
 where you have no writing rights, you cannot export your document to latex
 without incurring in those shortcomings. Nothing new.

Thank you for this clear explanation of what's going on.

It seems there is an enhancement that we can do. For example, we could
have a user-friendly dialog about not having write permissions to the
directory where an image is stored. The only alternative I can think
of is to change the path of the image to the same directory where the
.tex file is exported to.

Scott

Re: Math.lyx export to latex

[Kornel Benko]

Am Sonntag, 29. März 2015 um 23:07:35, schrieb Kornel Benko <kor...@lyx.org>
> This is a recipe to observe creation of files in lyx-source
> 
> 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say ~/lyx/test/.
>   This is not needed, but shows that the behaviour does not depend on
>   the path of Math.lyx
> 2.) use your lyx from the build directory to open the file
> 3.) File->Export->LaTeX(LuaLaTeX)
> 
> Now go to the lyx-source
> # git status
> 
> You see many untracked .pdf files like e.g. 
> lib/images/math-macro-remove-greedy-param.pdf
> 
> Second scenario with installed lyx. Make sure, the lyx system dirs are not 
> writeable by you
> 
> 2.) open the file
> 3.) try the export.
>   Now you are facing a dialog saying some file could not be copied.
>   Click OK.
>   Next dialog pops up.
>   This goes on for 43 files.
> 

Apparently nobody seems interested.

I tried to hunt it down with strace. For each created pdf file there is about 
3000 lines trace.
Too big to send, but some interesting lines are there, like
8951  open("/usr/src/lyx/lyx-git/lib/images/qt_temp.wv8939", 
O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 12
...
8951  rename("/usr/src/lyx/lyx-git/lib/images/qt_temp.wv8939", 
"/usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf") = 0
...
8951  
chmod("/usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf",
 0600) = 0

Looks like use of qt temporary files in lyx source.

OK, try to call lyx -dbg files, to hunt the messages in 
src/support/{TempFile,FileName,filetools}.cpp .
so here it is:
support/FileName.cpp (690): creating path 
'/usr/src/lyx/lyx-git/lib/images'.
support/FileName.cpp (590): Checksumming 
"/tmp/lyx_tmpdir.jloUpnFT9257/lyx_tmpbuf0/42_usr_src_lyx_lyx-git_lib_images_math-macro-add-greedy-optional-param.pdf"
 2022594892 lasted 1 ms.
support/FileName.cpp (230): Copying 
/usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf keep 
symlink: 0
support/FileName.cpp (590): Checksumming 
"/tmp/lyx_tmpdir.jloUpnFT9257/lyx_tmpbuf0/Math.tex" 3063457583 lasted 14 ms.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Kornel Benko]

I tried to debug, but ended at /usr/src/lyx/lyx-git/src/Exporter.cpp:142
FileMap::const_iterator cit = externalfiles_.find(format);

Here the log:
gdb) b FileName.cpp:690
Breakpoint 1, lyx::support::FileName::createPath (this=0x7fffe3ffe910) at 
/usr/src/lyx/lyx-git/src/support/FileName.cpp:690
690 LYXERR(Debug::FILES, "creating path '" << *this << "'.");
(gdb) up
#1  0x00c8d270 in lyx::Buffer::doExport (this=0x218a730, target=..., 
put_in_tempdir=false, includeall=false, result_file=...) at 
/usr/src/lyx/lyx-git/src/Buffer.cpp:4154
4154fixedFileName.onlyPath().createPath();
...
(gdb) p fixedName
$4 = {
  static npos = ,
  _M_dataplus = {
<std::allocator> = {
  <__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, 
std::allocator >::_Alloc_hider:
_M_p = 0x7fffdc0e5538 "/usr/src/lyx/lyx-git/lib/images/math-mode.pdf"
  }
}
(gdb) p dest
$2 = {
  static npos = ,
  _M_dataplus = {
<std::allocator> = {
  <__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, 
std::allocator >::_Alloc_hider:
_M_p = 0x7fffdc0f6688 "/home/kornel/lyx/test/"
  }
}
(gdb) p it->exportName
$5 = {
  static npos = ,
  _M_dataplus = {
<std::allocator> = {
  <__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, 
std::allocator >::_Alloc_hider:
_M_p = 0x7fffdc0e5538 "/usr/src/lyx/lyx-git/lib/images/math-mode.pdf"
  }
}
(gdb) p format
$7 = {
  static npos = ,
  _M_dataplus = {
<std::allocator> = {
  <__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, 
std::allocator >::_Alloc_hider:
_M_p = 0x2f955f8 "luatex"
  }
}
(gdb) p fmt
$8 = {
  static npos = ,
  _M_dataplus = {
<std::allocator> = {
  <__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, 
std::allocator >::_Alloc_hider:
_M_p = 0x7fffdc0fcc18 "pdf6"
  }
}
...

What I do not understand, why it->exportName references (incorrectly in my 
eyes) /usr/src/lyx/lyx-git/lib/images/math-mode.pdf
although dest is set to /home/kornel/lyx/test/. (This is the dir where Math.lyx 
lies)

Next try was to stop at Buffer.cpp:4134 (vector const files = ...)
only to stop at above mentioned Exporter.cpp.

Please help.

Kornel

Am Montag, 30. März 2015 um 11:26:23, schrieb Kornel Benko <kor...@lyx.org>
> Am Sonntag, 29. März 2015 um 23:07:35, schrieb Kornel Benko <kor...@lyx.org>
> > This is a recipe to observe creation of files in lyx-source
> > 
> > 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say 
> > ~/lyx/test/.
> > This is not needed, but shows that the behaviour does not depend on
> > the path of Math.lyx
> > 2.) use your lyx from the build directory to open the file
> > 3.) File->Export->LaTeX(LuaLaTeX)
> > 
> > Now go to the lyx-source
> > # git status
> > 
> > You see many untracked .pdf files like e.g. 
> > lib/images/math-macro-remove-greedy-param.pdf
> > 
> > Second scenario with installed lyx. Make sure, the lyx system dirs are not 
> > writeable by you
> > 
> > 2.) open the file
> > 3.) try the export.
> > Now you are facing a dialog saying some file could not be copied.
> > Click OK.
> > Next dialog pops up.
> > This goes on for 43 files.
> > 
> 
> Apparently nobody seems interested.
> 
> I tried to hunt it down with strace. For each created pdf file there is about 
> 3000 lines trace.
> Too big to send, but some interesting lines are there, like
>   8951  open("/usr/src/lyx/lyx-git/lib/images/qt_temp.wv8939", 
> O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 12
>   ...
>   8951  rename("/usr/src/lyx/lyx-git/lib/images/qt_temp.wv8939", 
> "/usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf") = > 0
>   ...
>   8951  
> chmod("/usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf",
>  0600) = 0
> 
> Looks like use of qt temporary files in lyx source.
> 
> OK, try to call lyx -dbg files, to hunt the messages in 
> src/support/{TempFile,FileName,filetools}.cpp .
> so here it is:
>   support/FileName.cpp (690): creating path 
> '/usr/src/lyx/lyx-git/lib/images'.
>   support/FileName.cpp (590): Checksumming 
> "/tmp/lyx_tmpdir.jloUpnFT9257/lyx_tmpbuf0/42_usr_src_lyx_lyx-git_lib_images_math-macro-add-greedy-optional-param.pdf"
>  2022594892 lasted 1 ms.
>   support/FileName.cpp (230): Copying 
> /usr/src/lyx/lyx-git/lib/images/math-macro-add-greedy-optional-param.pdf keep 
> symlink: 0
>   support/FileName.cpp (590): Checksumming 
> "/tmp/lyx_tmpdir.jloUpnFT9257/lyx_tmpbuf0/Math.tex" 3063457583 lasted 14 ms.
> 
>   Kornel
>   

signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Georg Baum]

Kornel Benko wrote:

> This is a recipe to observe creation of files in lyx-source
> 
> 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say
> ~/lyx/test/. This is not needed, but shows that the behaviour does not
> depend on the path of Math.lyx
> 2.) use your lyx from the build directory to open the file
> 3.) File->Export->LaTeX(LuaLaTeX)
> 
> Now go to the lyx-source
> # git status
> 
> You see many untracked .pdf files like e.g.
> lib/images/math-macro-remove-greedy-param.pdf

Are you sure that the correct file is opened? Maybe some black magic for 
special handling of our own docs goes havoc here? Or is is source control? I 
would expect the creation of those files if Math.lyx in the git source tree 
is opened (for LaTeX export we generate a document that can be processed by 
LaTeX, so we need to convert all included files that need conversion).

> Second scenario with installed lyx. Make sure, the lyx system dirs are not
> writeable by you
> 
> 2.) open the file
> 3.) try the export.
> Now you are facing a dialog saying some file could not be copied.

This looks again as if the file from the installation was opened.

> Click OK.
> Next dialog pops up.
> This goes on for 43 files.

The dialog should have a don't show me again button. If this is not the case 
please file a bug.

Unfortunately I don't have time to investigate now, but I'd guess that 
neither Exporter.cpp nor TempFile is the culprit. It is normal for the 
conversion process to use temporary files. The path of the temp file looks 
wrong (it should not be in the source tree), but this is probably an 
independent problem. Also, Exporter.cpp is probably simply fed with the 
wrong names.

I'd first check all places were the buffer file name is set and the buffer 
opening. If this is correct then I'd examine the info inset, maybe it 
creates some intermediate files at the wrong place.


Georg

Re: Math.lyx export to latex

[Kornel Benko]

Am Montag, 30. März 2015 um 22:23:38, schrieb Georg Baum 
<georg.b...@post.rwth-aachen.de>
> Kornel Benko wrote:
>
> > This is a recipe to observe creation of files in lyx-source
> >
> > 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say
> > ~/lyx/test/. This is not needed, but shows that the behaviour does not
> > depend on the path of Math.lyx
> > 2.) use your lyx from the build directory to open the file
> > 3.) File->Export->LaTeX(LuaLaTeX)
> >
> > Now go to the lyx-source
> > # git status
> >
> > You see many untracked .pdf files like e.g.
> > lib/images/math-macro-remove-greedy-param.pdf
>
> Are you sure that the correct file is opened?

Yes, I am sure.

> Maybe some black magic for
> special handling of our own docs goes havoc here?

No, it is direct copy of lib/doc/Math.lyx.

> Or is is source control?

I checked, clean source, clean build.

> I
> would expect the creation of those files if Math.lyx in the git source tree
> is opened (for LaTeX export we generate a document that can be processed by
> LaTeX, so we need to convert all included files that need conversion).

Yes, therefore I copied first to eliminate this possibility.

> > Second scenario with installed lyx. Make sure, the lyx system dirs are not
> > writeable by you

That is the case. If I make them writeable, there is no problem with export any 
more.
But of course, there are many new .pdf files there.

> > 2.) open the file
> > 3.) try the export.
> > Now you are facing a dialog saying some file could not be copied.
>
> This looks again as if the file from the installation was opened.

It is not.

> > Click OK.
> > Next dialog pops up.
> > This goes on for 43 files.
>
> The dialog should have a don't show me again button. If this is not the case
> please file a bug.

No such button. See attached (the first dialog).

> Unfortunately I don't have time to investigate now, but I'd guess that
> neither Exporter.cpp nor TempFile is the culprit. It is normal for the
> conversion process to use temporary files. The path of the temp file looks
> wrong (it should not be in the source tree), but this is probably an
> independent problem. Also, Exporter.cpp is probably simply fed with the
> wrong names.
>
> I'd first check all places were the buffer file name is set and the buffer
> opening. If this is correct then I'd examine the info inset, maybe it
> creates some intermediate files at the wrong place.
>
I tried and failed.

> Georg

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Georg Baum]

Kornel Benko wrote:

> Am Montag, 30. März 2015 um 22:23:38, schrieb Georg Baum
> 
>> Unfortunately I don't have time to investigate now, but I'd guess that
>> neither Exporter.cpp nor TempFile is the culprit. It is normal for the
>> conversion process to use temporary files. The path of the temp file
>> looks wrong (it should not be in the source tree), but this is probably
>> an independent problem. Also, Exporter.cpp is probably simply fed with
>> the wrong names.
>> 
>> I'd first check all places were the buffer file name is set and the
>> buffer opening. If this is correct then I'd examine the info inset, maybe
>> it creates some intermediate files at the wrong place.
>> 
> I tried and failed.

Since you verified that the opened .lyx file is the correct one the info 
inset becomes the most likely candidate. I had a quick look through the 
sources and there are two possible problems:

1) The temporary QImage which is created (line 423). It is easy to check 
whether this is the reason, since the QImage is not created for commandline 
export. Does the problem also occur for commandline export?

2) The temporary graphics inset which is created (line 429). The creation 
looks OK, but maybe the graphics inset has a bug. I'd continue the search 
there if the commandline export produces the files as well.


Georg

Re: Math.lyx export to latex

[Kornel Benko]

Am Montag, 30. März 2015 um 22:52:20, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Am Montag, 30. März 2015 um 22:23:38, schrieb Georg Baum
> > 
> >> Unfortunately I don't have time to investigate now, but I'd guess that
> >> neither Exporter.cpp nor TempFile is the culprit. It is normal for the
> >> conversion process to use temporary files. The path of the temp file
> >> looks wrong (it should not be in the source tree), but this is probably
> >> an independent problem. Also, Exporter.cpp is probably simply fed with
> >> the wrong names.
> >> 
> >> I'd first check all places were the buffer file name is set and the
> >> buffer opening. If this is correct then I'd examine the info inset, maybe
> >> it creates some intermediate files at the wrong place.
> >> 
> > I tried and failed.
> 
> Since you verified that the opened .lyx file is the correct one the info 
> inset becomes the most likely candidate. I had a quick look through the 
> sources and there are two possible problems:
> 
> 1) The temporary QImage which is created (line 423). It is easy to check 
> whether this is the reason, since the QImage is not created for commandline 
> export. Does the problem also occur for commandline export?

Yes, but is not visible on installed directories. There is no dialog and the 
exported
file Math.tex is OK. (As is also from the GUI, only with 43 dialogs to click to 
OK)

Exporting with lyx from the build-dir creates the pfd files in lyx source.
# cd buil-dir
# ./bin/lyx2.2 -e luatex ~/lyx/test/Math.lyx
# cd source-dir
# git status | grep pdf | wc
 19  19 517

If I set for the oxygen user interface I get
# git status | grep pdf | wc
50  501898

> 2) The temporary graphics inset which is created (line 429). The creation 
> looks OK, but maybe the graphics inset has a bug. I'd continue the search 
> there if the commandline export produces the files as well.

Thanks

> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Math.lyx export to latex

[Enrico Forestieri]

On Sun, Mar 29, 2015 at 11:07:35PM +0200, Kornel Benko wrote:

> This is a recipe to observe creation of files in lyx-source
> 
> 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say ~/lyx/test/.
>   This is not needed, but shows that the behaviour does not depend on
>   the path of Math.lyx
> 2.) use your lyx from the build directory to open the file
> 3.) File->Export->LaTeX(LuaLaTeX)
> 
> Now go to the lyx-source
> # git status
> 
> You see many untracked .pdf files like e.g. 
> lib/images/math-macro-remove-greedy-param.pdf

I think this is the expected behavior. When you export to latex, in order
to ensure compilation, all images gets converted to a format that latex
understands. If you reference a svg image and export to pdflatex, this
image has to be converted. On the other hand, if you reference a png image
no conversion is needed, because pdflatex can deal with pngs.

Note that it means nothing that you saved elsewhere the document, because
full paths are still used to point to the original images (that are not
moved alongside the document, or that are always found in the lyx installation
directory for the icon info inset). Also note that the icon info inset is
simply equivalent to the graphics inset.

This is nothing new, I think, and you should have got the same result if
you tried exporting to plain latex in the case of png icons, because in
this case all pngs should be converted to postscript. However, nobody
seems producing dvi or postscript output for the lyx documentation and
thus this was going unnoticed when the icons were in png format.

This only occurs if you first export to latex, but of course you can always
produce output directly from lyx, because in this case all images are
copied to the temporary directory.

In conclusion, if your document references an image located in a directory
where you have no writing rights, you cannot export your document to latex
without incurring in those shortcomings. Nothing new.

> Second scenario with installed lyx. Make sure, the lyx system dirs are not 
> writeable by you
> 
> 2.) open the file
> 3.) try the export.
>   Now you are facing a dialog saying some file could not be copied.
>   Click OK.
>   Next dialog pops up.
>   This goes on for 43 files.

Of course, this is also expected.

-- 
Enrico

Re: Math.lyx export to latex

[Scott Kostyshak]

On Mon, Mar 30, 2015 at 8:12 PM, Enrico Forestieri <for...@lyx.org> wrote:
> On Sun, Mar 29, 2015 at 11:07:35PM +0200, Kornel Benko wrote:
>
>> This is a recipe to observe creation of files in lyx-source
>>
>> 1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say ~/lyx/test/.
>>   This is not needed, but shows that the behaviour does not depend on
>>   the path of Math.lyx
>> 2.) use your lyx from the build directory to open the file
>> 3.) File->Export->LaTeX(LuaLaTeX)
>>
>> Now go to the lyx-source
>> # git status
>>
>> You see many untracked .pdf files like e.g. 
>> lib/images/math-macro-remove-greedy-param.pdf
>
> I think this is the expected behavior. When you export to latex, in order
> to ensure compilation, all images gets converted to a format that latex
> understands. If you reference a svg image and export to pdflatex, this
> image has to be converted. On the other hand, if you reference a png image
> no conversion is needed, because pdflatex can deal with pngs.
>
> Note that it means nothing that you saved elsewhere the document, because
> full paths are still used to point to the original images (that are not
> moved alongside the document, or that are always found in the lyx installation
> directory for the icon info inset). Also note that the icon info inset is
> simply equivalent to the graphics inset.
>
> This is nothing new, I think, and you should have got the same result if
> you tried exporting to plain latex in the case of png icons, because in
> this case all pngs should be converted to postscript. However, nobody
> seems producing dvi or postscript output for the lyx documentation and
> thus this was going unnoticed when the icons were in png format.
>
> This only occurs if you first export to latex, but of course you can always
> produce output directly from lyx, because in this case all images are
> copied to the temporary directory.
>
> In conclusion, if your document references an image located in a directory
> where you have no writing rights, you cannot export your document to latex
> without incurring in those shortcomings. Nothing new.

Thank you for this clear explanation of what's going on.

It seems there is an enhancement that we can do. For example, we could
have a user-friendly dialog about not having write permissions to the
directory where an image is stored. The only alternative I can think
of is to change the path of the image to the same directory where the
.tex file is exported to.

Scott

Math.lyx export to latex

[Kornel Benko]

This is a recipe to observe creation of files in lyx-source

1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say ~/lyx/test/.
This is not needed, but shows that the behaviour does not depend on
the path of Math.lyx
2.) use your lyx from the build directory to open the file
3.) File-Export-LaTeX(LuaLaTeX)

Now go to the lyx-source
# git status

You see many untracked .pdf files like e.g. 
lib/images/math-macro-remove-greedy-param.pdf

Second scenario with installed lyx. Make sure, the lyx system dirs are not 
writeable by you

2.) open the file
3.) try the export.
Now you are facing a dialog saying some file could not be copied.
Click OK.
Next dialog pops up.
This goes on for 43 files.

Kornel


signature.asc
Description: This is a digitally signed message part.

Math.lyx export to latex

[Kornel Benko]

This is a recipe to observe creation of files in lyx-source

1.) copy {lyx-source}/lib/doc/Math.lyx to a local directory, say ~/lyx/test/.
This is not needed, but shows that the behaviour does not depend on
the path of Math.lyx
2.) use your lyx from the build directory to open the file
3.) File->Export->LaTeX(LuaLaTeX)

Now go to the lyx-source
# git status

You see many untracked .pdf files like e.g. 
lib/images/math-macro-remove-greedy-param.pdf

Second scenario with installed lyx. Make sure, the lyx system dirs are not 
writeable by you

2.) open the file
3.) try the export.
Now you are facing a dialog saying some file could not be copied.
Click OK.
Next dialog pops up.
This goes on for 43 files.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: Export to Latex and Overwriting Included Images

[Anders Host-Madsen]

Thanks. I think at least there should be a 'skip' option for the eps  
files.

On Jan 17, 2009, at 10:22 PM, Konrad Hofbauer wrote:


Hello,

Anders Host-Madsen wrote:
 Thanks for your help. After getting a better understanding of LyX  
I now

 understand what is going on. The .eps files that LyX can render were
 generated by LyX itself (!), as follows: I converted the graphic  
from
 .eps to .pdf, which I included in LyX. Then I exported the file as  
plain
 LaTeX. By that LyX converted the .pdf back to .eps, and overwrote  
the

 original .eps file (so those identical .eps files in different
 directories were in fact different).


People sometimes have identical PDF and EPS versions of their images  
in the same folder, with, e.g., troublesome EPS files manually  
converted, or both versions directly exported from the source program.


If the PDF-version is included as image, it is impossible to export  
to latex(plain) without overwriting the existing EPS version with a  
new version (created by ghostscript).  There is a warning at least,  
but still it means no export without data loss in the existing EPS  
file.


The warning dialogue only allows overwrite, overwrite all, and  
cancel export.


Should I file this as bug/enhancement request?

Thanks,
Konrad



Anders Host-Madsen
Associate Professor
Department of Electrical Engineering
University of Hawaii, Honolulu, HI 96822
e-mail: mad...@spectra.eng.hawaii.edu
phone: (808) 956-2693 fax: (808) 956-3427
http://www.hostmadsen.com

Re: Export to Latex and Overwriting Included Images

[Anders Host-Madsen]

Thanks. I think at least there should be a 'skip' option for the eps  
files.

On Jan 17, 2009, at 10:22 PM, Konrad Hofbauer wrote:


Hello,

Anders Host-Madsen wrote:
> Thanks for your help. After getting a better understanding of LyX  
I now

> understand what is going on. The .eps files that LyX can render were
> generated by LyX itself (!), as follows: I converted the graphic  
from
> .eps to .pdf, which I included in LyX. Then I exported the file as  
plain
> LaTeX. By that LyX converted the .pdf back to .eps, and overwrote  
the

> original .eps file (so those identical .eps files in different
> directories were in fact different).


People sometimes have identical PDF and EPS versions of their images  
in the same folder, with, e.g., troublesome EPS files manually  
converted, or both versions directly exported from the source program.


If the PDF-version is included as image, it is impossible to export  
to latex(plain) without overwriting the existing EPS version with a  
new version (created by ghostscript).  There is a warning at least,  
but still it means no export without data loss in the existing EPS  
file.


The warning dialogue only allows overwrite, overwrite all, and  
cancel export.


Should I file this as bug/enhancement request?

Thanks,
Konrad



Anders Host-Madsen
Associate Professor
Department of Electrical Engineering
University of Hawaii, Honolulu, HI 96822
e-mail: mad...@spectra.eng.hawaii.edu
phone: (808) 956-2693 fax: (808) 956-3427
http://www.hostmadsen.com

Re: no way to export as latex

[Richard Heck]

abdelkader belahcene wrote:
 thanks for reply,
 I want to generate the latex file from the lyx file, this option
 existed in the previous release; file---export ---latex, like
 file--export---pdf  ,  html and other
This option does exist in 1.5.beta1. At least, it does in my copy. There
are two such options: Latex (plain) and Latex (pdflatex). If you're not
seeing it, I'm not sure why that would be.

Richard

 On 4/7/07, Richard Heck [EMAIL PROTECTED] wrote:
 abdelkader belahcene wrote:
  Hi,

 best regards

 bela


  I just installed the lyx-1.5beta, I am surprised that no export type
  exist specially for latex. If this exists we can do others with
  commands ( dvips, latex2html ). the right buttons generate only
  ps, pdf, dvi. Why is it omitted ??
 I don't understand. Don't you have FileExportLatex?

 Richard

 -- 
 ==
 Richard G Heck, Jr
 Professor of Philosophy
 Brown University
 http://frege.brown.edu/heck/
 ==
 Get my public key from http://sks.keyserver.penguin.de
 Hash: 0x1DE91F1E66FFBDEC
 Learn how to sign your email using Thunderbird and GnuPG at:
 http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto




-- 
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Re: no way to export as latex

[Richard Heck]

abdelkader belahcene wrote:
> thanks for reply,
> I want to generate the latex file from the lyx file, this option
> existed in the previous release; file--->export --->latex, like
> file-->export--->pdf  ,  html and other
This option does exist in 1.5.beta1. At least, it does in my copy. There
are two such options: Latex (plain) and Latex (pdflatex). If you're not
seeing it, I'm not sure why that would be.

Richard
>
> On 4/7/07, Richard Heck <[EMAIL PROTECTED]> wrote:
>> abdelkader belahcene wrote:
>> > Hi,
>
> best regards
>
> bela
>
>
>> > I just installed the lyx-1.5beta, I am surprised that no export type
>> > exist specially for latex. If this exists we can do others with
>> > commands ( dvips, latex2html ). the right buttons generate only
>> > ps, pdf, dvi. Why is it omitted ??
>> I don't understand. Don't you have File>Export>Latex?
>>
>> Richard
>>
>> -- 
>> ==
>> Richard G Heck, Jr
>> Professor of Philosophy
>> Brown University
>> http://frege.brown.edu/heck/
>> ==
>> Get my public key from http://sks.keyserver.penguin.de
>> Hash: 0x1DE91F1E66FFBDEC
>> Learn how to sign your email using Thunderbird and GnuPG at:
>> http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
>>
>>


-- 
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Re: [Fwd: export to latex]

[Andre Poenitz]

On Fri, Oct 27, 2006 at 11:05:51AM +0200, Edwin Leuven wrote:
 sometime ago i wrote:
 
  Original Message 
 Subject: export to latex
 Date: Tue, 02 May 2006 20:53:01 +0200
 From: Edwin Leuven [EMAIL PROTECTED]
 To: LyX Developers lyx-devel@lists.lyx.org
 
 an old annoyance of mine is the following:
 
 when exporting to latex, each cell of a table is on its own line.
 
 with the attached each row is on its own line which i find much better.
 
 opinions (flames)?
 
 thanks, ed.
  Original Message 
 
 
 
 i'd like to put it in. objections?

 Index: src/tabular.C
 ===
 --- src/tabular.C (revision 13787)
 +++ src/tabular.C (working copy)
 @@ -2034,7 +2034,7 @@
  
   ret += TeXCellPostamble(os, cell);
   if (!isLastCellInRow(cell)) { // not last cell in row
 - os  \n;
 + os;

Be _very_ careful when adding spaces to .tex output.

Having all in one row make only sense if the rows are short...

Andre'

Re: [Fwd: export to latex]

[Herbert Voss]

Andre Poenitz schrieb:
 On Fri, Oct 27, 2006 at 11:05:51AM +0200, Edwin Leuven wrote:
 sometime ago i wrote:

  Original Message 
 Subject: export to latex
 Date: Tue, 02 May 2006 20:53:01 +0200
 From: Edwin Leuven [EMAIL PROTECTED]
 To: LyX Developers lyx-devel@lists.lyx.org

 an old annoyance of mine is the following:

 when exporting to latex, each cell of a table is on its own line.

 with the attached each row is on its own line which i find much better.

 opinions (flames)?

 thanks, ed.
  Original Message 



 i'd like to put it in. objections?
 
 Index: src/tabular.C
 ===
 --- src/tabular.C(revision 13787)
 +++ src/tabular.C(working copy)
 @@ -2034,7 +2034,7 @@
  
  ret += TeXCellPostamble(os, cell);
  if (!isLastCellInRow(cell)) { // not last cell in row
 -os  \n;
 +os;
 
 Be _very_ careful when adding spaces to .tex output.

not in this case, where a space is useful for a pretty output.

 Having all in one row make only sense if the rows are short...

the LaTeX export of tables from LyX is a mess ... at least you should
have

  cell entry
  cell entry\\
...

Herbert

Re: [Fwd: export to latex]

[Andre Poenitz]

On Fri, Oct 27, 2006 at 11:05:51AM +0200, Edwin Leuven wrote:
> sometime ago i wrote:
> 
>  Original Message 
> Subject: export to latex
> Date: Tue, 02 May 2006 20:53:01 +0200
> From: Edwin Leuven <[EMAIL PROTECTED]>
> To: LyX Developers <lyx-devel@lists.lyx.org>
> 
> an old annoyance of mine is the following:
> 
> when exporting to latex, each cell of a table is on its own line.
> 
> with the attached each row is on its own line which i find much better.
> 
> opinions (flames)?
> 
> thanks, ed.
>  Original Message 
> 
> 
> 
> i'd like to put it in. objections?

> Index: src/tabular.C
> ===
> --- src/tabular.C (revision 13787)
> +++ src/tabular.C (working copy)
> @@ -2034,7 +2034,7 @@
>  
>   ret += TeXCellPostamble(os, cell);
>   if (!isLastCellInRow(cell)) { // not last cell in row
> - os << "&\n";
> + os << " & ";

Be _very_ careful when adding spaces to .tex output.

Having all in one row make only sense if the rows are short...

Andre'

Re: [Fwd: export to latex]

[Herbert Voss]

Andre Poenitz schrieb:
> On Fri, Oct 27, 2006 at 11:05:51AM +0200, Edwin Leuven wrote:
>> sometime ago i wrote:
>>
>>  Original Message ----
>> Subject: export to latex
>> Date: Tue, 02 May 2006 20:53:01 +0200
>> From: Edwin Leuven <[EMAIL PROTECTED]>
>> To: LyX Developers <lyx-devel@lists.lyx.org>
>>
>> an old annoyance of mine is the following:
>>
>> when exporting to latex, each cell of a table is on its own line.
>>
>> with the attached each row is on its own line which i find much better.
>>
>> opinions (flames)?
>>
>> thanks, ed.
>>  Original Message 
>>
>>
>>
>> i'd like to put it in. objections?
> 
>> Index: src/tabular.C
>> ===
>> --- src/tabular.C(revision 13787)
>> +++ src/tabular.C(working copy)
>> @@ -2034,7 +2034,7 @@
>>  
>>  ret += TeXCellPostamble(os, cell);
>>  if (!isLastCellInRow(cell)) { // not last cell in row
>> -os << "&\n";
>> +    os << " & ";
> 
> Be _very_ careful when adding spaces to .tex output.

not in this case, where a space is useful for a pretty output.

> Having all in one row make only sense if the rows are short...

the LaTeX export of tables from LyX is a mess ... at least you should
have

 & cell entry
 & cell entry\\
...

Herbert

[Fwd: export to latex]

[Edwin Leuven]

sometime ago i wrote:

 Original Message 
Subject: export to latex
Date: Tue, 02 May 2006 20:53:01 +0200
From: Edwin Leuven [EMAIL PROTECTED]
To: LyX Developers lyx-devel@lists.lyx.org

an old annoyance of mine is the following:

when exporting to latex, each cell of a table is on its own line.

with the attached each row is on its own line which i find much better.

opinions (flames)?

thanks, ed.
 Original Message 



i'd like to put it in. objections?
Index: src/tabular.C
===
--- src/tabular.C   (revision 13787)
+++ src/tabular.C   (working copy)
@@ -2034,7 +2034,7 @@
 
ret += TeXCellPostamble(os, cell);
if (!isLastCellInRow(cell)) { // not last cell in row
-   os  \n;
+   os;
++ret;
}
++cell;

Re: [Fwd: export to latex]

[Jean-Marc Lasgouttes]

 Edwin == Edwin Leuven [EMAIL PROTECTED] writes:

Edwin sometime ago i wrote:  Original Message 
Edwin Subject: export to latex Date: Tue, 02 May 2006 20:53:01 +0200
Edwin From: Edwin Leuven [EMAIL PROTECTED] To: LyX Developers
Edwin lyx-devel@lists.lyx.org

Edwin an old annoyance of mine is the following:

Edwin when exporting to latex, each cell of a table is on its own
Edwin line.

Edwin with the attached each row is on its own line which i find much
Edwin better.

The patch is wrong. If you do not add a \n, you should not increase
ret, which counts lines.

Other that that, I am not against such a patch. But of course, people
who use large tables will not be happy either. It is a bit difficult
to please everybody for output format problems.

JMarc

Re: [Fwd: export to latex]

[Edwin Leuven]

Jean-Marc Lasgouttes wrote:

The patch is wrong. If you do not add a \n, you should not increase
ret, which counts lines.


thanks, update attached


Other that that, I am not against such a patch. But of course, people
who use large tables will not be happy either. It is a bit difficult
to please everybody for output format problems.


i think that this is a uniform improvement (even for people who use 
large tables such as myself)


will commit soon...
Index: tabular.C
===
--- tabular.C   (revision 15573)
+++ tabular.C   (working copy)
@@ -2158,8 +2158,7 @@
 
ret += TeXCellPostamble(os, cell);
if (!isLastCellInRow(cell)) { // not last cell in row
-   os  \n;
-   ++ret;
+   os;
}
++cell;
}

Re: [Fwd: export to latex]

[Edwin Leuven]

Edwin Leuven wrote:

will commit soon...


it's in

[Fwd: export to latex]

[Edwin Leuven]

sometime ago i wrote:

 Original Message 
Subject: export to latex
Date: Tue, 02 May 2006 20:53:01 +0200
From: Edwin Leuven <[EMAIL PROTECTED]>
To: LyX Developers <lyx-devel@lists.lyx.org>

an old annoyance of mine is the following:

when exporting to latex, each cell of a table is on its own line.

with the attached each row is on its own line which i find much better.

opinions (flames)?

thanks, ed.
 Original Message 



i'd like to put it in. objections?
Index: src/tabular.C
===
--- src/tabular.C   (revision 13787)
+++ src/tabular.C   (working copy)
@@ -2034,7 +2034,7 @@
 
ret += TeXCellPostamble(os, cell);
if (!isLastCellInRow(cell)) { // not last cell in row
-   os << "&\n";
+   os << " & ";
++ret;
}
++cell;

Re: [Fwd: export to latex]

[Jean-Marc Lasgouttes]

>>>>> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:

Edwin> sometime ago i wrote:  Original Message ----
Edwin> Subject: export to latex Date: Tue, 02 May 2006 20:53:01 +0200
Edwin> From: Edwin Leuven <[EMAIL PROTECTED]> To: LyX Developers
Edwin> <lyx-devel@lists.lyx.org>

Edwin> an old annoyance of mine is the following:

Edwin> when exporting to latex, each cell of a table is on its own
Edwin> line.

Edwin> with the attached each row is on its own line which i find much
Edwin> better.

The patch is wrong. If you do not add a \n, you should not increase
"ret", which counts lines.

Other that that, I am not against such a patch. But of course, people
who use large tables will not be happy either. It is a bit difficult
to please everybody for output format problems.

JMarc

Re: [Fwd: export to latex]

[Edwin Leuven]

Jean-Marc Lasgouttes wrote:

The patch is wrong. If you do not add a \n, you should not increase
"ret", which counts lines.


thanks, update attached


Other that that, I am not against such a patch. But of course, people
who use large tables will not be happy either. It is a bit difficult
to please everybody for output format problems.


i think that this is a uniform improvement (even for people who use 
large tables such as myself)


will commit soon...
Index: tabular.C
===
--- tabular.C   (revision 15573)
+++ tabular.C   (working copy)
@@ -2158,8 +2158,7 @@
 
ret += TeXCellPostamble(os, cell);
if (!isLastCellInRow(cell)) { // not last cell in row
-   os << "&\n";
-   ++ret;
+   os << " & ";
}
++cell;
}

Re: [Fwd: export to latex]

[Edwin Leuven]

Edwin Leuven wrote:

will commit soon...


it's in

UTF-8 export to LaTeX works

[Asger Ottar Alstrup]

Hi,

I just committed a few fixes to get UTF-8 latex export working.

Regards,
Asger
Index: bufferparams.C
===
--- bufferparams.C  (revision 15381)
+++ bufferparams.C  (working copy)
@@ -839,26 +839,32 @@
texrow.newline();
}
 
-   if (inputenc == auto) {
-   string const doc_encoding =
-   language-encoding()-latexName();
+   // TODO: Some people want to support more encodings than UTF-8. They 
can have a field day around here
+   if (true) {
+   os  \\usepackage[utf8]{inputenc}\n;
+   texrow.newline();
+   } else {
+   if (inputenc == auto) {
+   string const doc_encoding =
+   language-encoding()-latexName();
 
-   // Create a list with all the input encodings used
-   // in the document
-   std::setstring encodings =
-   features.getEncodingSet(doc_encoding);
+   // Create a list with all the input encodings used
+   // in the document
+   std::setstring encodings =
+   features.getEncodingSet(doc_encoding);
 
-   os  \\usepackage[;
-   std::setstring::const_iterator it = encodings.begin();
-   std::setstring::const_iterator const end = encodings.end();
-   for (; it != end; ++it)
-   os  lyx::from_ascii(*it)  ',';
-   os  lyx::from_ascii(doc_encoding)  ]{inputenc}\n;
-   texrow.newline();
-   } else if (inputenc != default) {
-   os  \\usepackage[  lyx::from_ascii(inputenc)
-   ]{inputenc}\n;
-   texrow.newline();
+   os  \\usepackage[;
+   std::setstring::const_iterator it = encodings.begin();
+   std::setstring::const_iterator const end = 
encodings.end();
+   for (; it != end; ++it)
+   os  lyx::from_ascii(*it)  ',';
+   os  lyx::from_ascii(doc_encoding)  ]{inputenc}\n;
+   texrow.newline();
+   } else if (inputenc != default) {
+   os  \\usepackage[  lyx::from_ascii(inputenc)
+   ]{inputenc}\n;
+   texrow.newline();
+   }
}
 
if (use_geometry || nonstandard_papersize) {
Index: mathed/InsetMathMBox.C
===
--- mathed/InsetMathMBox.C  (revision 15381)
+++ mathed/InsetMathMBox.C  (working copy)
@@ -25,10 +25,10 @@
 #include paragraph.h
 #include texrow.h
 
+using lyx::odocstream;
 using std::auto_ptr;
 using std::endl;
 
-
 InsetMathMBox::InsetMathMBox(BufferView  bv)
: text_(bv), bv_(bv)
 {
@@ -73,7 +73,7 @@
ws  };
} else {
ws  \\mbox{\n;
-   text_.write(*bv_-buffer(), ws.os());
+// text_.write(*bv_-buffer(), ws.os());
ws  };
}
 }
Index: output_latex.C
===
--- output_latex.C  (revision 15381)
+++ output_latex.C  (working copy)
@@ -292,12 +292,14 @@
}
}
 
-   if (bparams.inputenc == auto 
-   language-encoding() != previous_language-encoding()) {
-   os  \\inputencoding{
-   lyx::from_ascii(language-encoding()-latexName())
-   }\n;
-   texrow.newline();
+   if (false) {
+   if (bparams.inputenc == auto 
+   language-encoding() != previous_language-encoding()) {
+   os  \\inputencoding{
+   lyx::from_ascii(language-encoding()-latexName())
+   }\n;
+   texrow.newline();
+   }
}
 
// In an an inset with unlimited length (all in one row),
Index: paragraph_pimpl.C
===
--- paragraph_pimpl.C   (revision 15381)
+++ paragraph_pimpl.C   (working copy)
@@ -666,7 +666,7 @@
// I assume this is hack treating typewriter as verbatim
if (font.family() == LyXFont::TYPEWRITER_FAMILY) {
if (c != '\0') {
-   os  c;
+   os.put(c);
}
break;
}
@@ -691,7 +691,7 @@
}
 
if (pnr == phrases_nr  c != '\0') {
-   os  c;
+   os.put(c);
}
break;
}

UTF-8 export to LaTeX works

[Asger Ottar Alstrup]

Hi,

I just committed a few fixes to get UTF-8 latex export working.

Regards,
Asger
Index: bufferparams.C
===
--- bufferparams.C  (revision 15381)
+++ bufferparams.C  (working copy)
@@ -839,26 +839,32 @@
texrow.newline();
}
 
-   if (inputenc == "auto") {
-   string const doc_encoding =
-   language->encoding()->latexName();
+   // TODO: Some people want to support more encodings than UTF-8. They 
can have a field day around here
+   if (true) {
+   os << "\\usepackage[utf8]{inputenc}\n";
+   texrow.newline();
+   } else {
+   if (inputenc == "auto") {
+   string const doc_encoding =
+   language->encoding()->latexName();
 
-   // Create a list with all the input encodings used
-   // in the document
-   std::set encodings =
-   features.getEncodingSet(doc_encoding);
+   // Create a list with all the input encodings used
+   // in the document
+   std::set encodings =
+   features.getEncodingSet(doc_encoding);
 
-   os << "\\usepackage[";
-   std::set::const_iterator it = encodings.begin();
-   std::set::const_iterator const end = encodings.end();
-   for (; it != end; ++it)
-   os << lyx::from_ascii(*it) << ',';
-   os << lyx::from_ascii(doc_encoding) << "]{inputenc}\n";
-   texrow.newline();
-   } else if (inputenc != "default") {
-   os << "\\usepackage[" << lyx::from_ascii(inputenc)
-  << "]{inputenc}\n";
-   texrow.newline();
+   os << "\\usepackage[";
+   std::set::const_iterator it = encodings.begin();
+   std::set::const_iterator const end = 
encodings.end();
+   for (; it != end; ++it)
+   os << lyx::from_ascii(*it) << ',';
+   os << lyx::from_ascii(doc_encoding) << "]{inputenc}\n";
+   texrow.newline();
+   } else if (inputenc != "default") {
+   os << "\\usepackage[" << lyx::from_ascii(inputenc)
+  << "]{inputenc}\n";
+   texrow.newline();
+   }
}
 
if (use_geometry || nonstandard_papersize) {
Index: mathed/InsetMathMBox.C
===
--- mathed/InsetMathMBox.C  (revision 15381)
+++ mathed/InsetMathMBox.C  (working copy)
@@ -25,10 +25,10 @@
 #include "paragraph.h"
 #include "texrow.h"
 
+using lyx::odocstream;
 using std::auto_ptr;
 using std::endl;
 
-
 InsetMathMBox::InsetMathMBox(BufferView & bv)
: text_(), bv_()
 {
@@ -73,7 +73,7 @@
ws << "}";
} else {
ws << "\\mbox{\n";
-   text_.write(*bv_->buffer(), ws.os());
+// text_.write(*bv_->buffer(), ws.os());
ws << "}";
}
 }
Index: output_latex.C
===
--- output_latex.C  (revision 15381)
+++ output_latex.C  (working copy)
@@ -292,12 +292,14 @@
}
}
 
-   if (bparams.inputenc == "auto" &&
-   language->encoding() != previous_language->encoding()) {
-   os << "\\inputencoding{"
-  << lyx::from_ascii(language->encoding()->latexName())
-  << "}\n";
-   texrow.newline();
+   if (false) {
+   if (bparams.inputenc == "auto" &&
+   language->encoding() != previous_language->encoding()) {
+   os << "\\inputencoding{"
+  << lyx::from_ascii(language->encoding()->latexName())
+  << "}\n";
+   texrow.newline();
+   }
}
 
// In an an inset with unlimited length (all in one row),
Index: paragraph_pimpl.C
===
--- paragraph_pimpl.C   (revision 15381)
+++ paragraph_pimpl.C   (working copy)
@@ -666,7 +666,7 @@
// I assume this is hack treating typewriter as verbatim
  

Re: 1.4.2svn crash with view-postscript/dvi (export to latex?)

[Georg Baum]

Am Donnerstag, 25. Mai 2006 05:28 schrieb Bo Peng:

   if (lyx::support::rename(temp_file, new_file)) {
   temp_file = new_file;
   output_file = ChangeExtension(output_file, ext);
   source_file = ChangeExtension(output_file, ext);

My mistake. The last line slipped off the patch, I aded it later, and of 
course it should have been

source_file = ChangeExtension(source_file, ext);

I'll correct that now. Thanks for the investigation!


Georg

Re: 1.4.2svn crash with view->postscript/dvi (export to latex?)

[Georg Baum]

Am Donnerstag, 25. Mai 2006 05:28 schrieb Bo Peng:

>   if (lyx::support::rename(temp_file, new_file)) {
>   temp_file = new_file;
>   output_file = ChangeExtension(output_file, ext);
>   source_file = ChangeExtension(output_file, ext);

My mistake. The last line slipped off the patch, I aded it later, and of 
course it should have been

source_file = ChangeExtension(source_file, ext);

I'll correct that now. Thanks for the investigation!


Georg

1.4.2svn crash with view-postscript/dvi (export to latex?)

[Bo Peng]

Dear list,

lyx 1.4.2 cvs crashes when I try to view a file with eps figure. Here
is the gdb trace:

Assertion triggered in void ExportData::addExternalFile(const
std::string, const std::string, const std::string) by failing check
lyx::support::AbsolutePath(sourceName) in file exporter.C:322

Program received signal SIGABRT, Aborted.
[Switching to Thread -1208076064 (LWP 14569)]
0x00afd7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0  0x00afd7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00b3d7f5 in raise () from /lib/tls/libc.so.6
#2  0x00b3f199 in abort () from /lib/tls/libc.so.6
#3  0x0833d91b in lyx::support::abort () at abort.C:22
#4  0x080af4f8 in boost::assertion_failed (
   expr=0x83935f4 lyx::support::AbsolutePath(sourceName),
   function=0x8393620 void ExportData::addExternalFile(const
std::string, const std::string, const std::string), file=0x839350a
exporter.C, line=322) at boost.C:56
#5  0x080e8e6a in ExportData::addExternalFile (this=0x94626e0,
[EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED]) at exporter.C:322
#6  0x081ee909 in InsetGraphics::prepareFile (this=0x95da380, [EMAIL PROTECTED],
   [EMAIL PROTECTED]) at insetgraphics.C:700
#7  0x081ef373 in InsetGraphics::latex (this=0x95da380,
[EMAIL PROTECTED], [EMAIL PROTECTED],
   [EMAIL PROTECTED]) at insetgraphics.C:799
#8  0x08152339 in Paragraph::Pimpl::simpleTeXSpecialChars
(this=0x95da128, [EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
   [EMAIL PROTECTED], c=1 '\001') at paragraph_pimpl.C:582
#9  0x08149fa4 in Paragraph::simpleTeXOnePar (this=0x95da1e8, [EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED],
   [EMAIL PROTECTED]) at paragraph.C:1017
#10 0x081442ab in (anonymous namespace)::TeXOnePar ([EMAIL PROTECTED],
[EMAIL PROTECTED], pit=
 {_M_node = 0x95da1e0}, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED],
   [EMAIL PROTECTED]) at output_latex.C:337
#11 0x08144dd4 in latexParagraphs ([EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
at output_latex.C:512
#12 0x08206a0f in InsetText::latex (this=0x95d9f20, [EMAIL PROTECTED],
[EMAIL PROTECTED],
   [EMAIL PROTECTED]) at insettext.C:287
---Type return to continue, or q return to quit---q

Attached is the offending lyx file.

Bo


try.lyx
Description: Binary data

Re: 1.4.2svn crash with view-postscript/dvi (export to latex?)

[Bo Peng]

The problem is at line 683, insetgraphics.C

// source file is now full path
/tmp/lyx_tmpdir20237FyBZGA/lyx_tmpbuf0/4_home_bpeng_simuPOP_doc_log_LDdecay.eps

if (!runparams.nice  GetExtension(temp_file) != ext) {
// The LaTeX compiler will not be able to determine
// the file format from the extension, so we must
// change it.
string const new_file = ChangeExtension(temp_file, ext);
// change extension to
/tmp/lyx_tmpdir20237FyBZGA/lyx_tmpbuf0/4_home_bpeng_simuPOP_doc_log_LDdecay.ps

if (lyx::support::rename(temp_file, new_file)) {
temp_file = new_file;
output_file = ChangeExtension(output_file, ext);
source_file = ChangeExtension(output_file, ext);
// source_file is no longer full path name, since output_file is not full path
} else
lyxerr[Debug::GRAPHICS]
 Could not rename file `
 temp_file  ' to `  new_file
 '.  endl;
}
// The extension of temp_file might be != ext!
// source file is no longer full path name
runparams.exportdata-addExternalFile(tex_format, source_file,
  output_file);


OK, the problem is then turned to line 606,

string output_file = os::external_path(runparams.nice ?
params().filename.outputFilename(m_buffer-filePath()) :
OnlyFilename(temp_file));

Obviously, the OnlyFilename() call is in doubt here. I do not know why
it is used, when I remove it, the crash stops.

Bo

1.4.2svn crash with view->postscript/dvi (export to latex?)

[Bo Peng]

Dear list,

lyx 1.4.2 cvs crashes when I try to view a file with eps figure. Here
is the gdb trace:

Assertion triggered in void ExportData::addExternalFile(const
std::string&, const std::string&, const std::string&) by failing check
"lyx::support::AbsolutePath(sourceName)" in file exporter.C:322

Program received signal SIGABRT, Aborted.
[Switching to Thread -1208076064 (LWP 14569)]
0x00afd7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0  0x00afd7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00b3d7f5 in raise () from /lib/tls/libc.so.6
#2  0x00b3f199 in abort () from /lib/tls/libc.so.6
#3  0x0833d91b in lyx::support::abort () at abort.C:22
#4  0x080af4f8 in boost::assertion_failed (
   expr=0x83935f4 "lyx::support::AbsolutePath(sourceName)",
   function=0x8393620 "void ExportData::addExternalFile(const
std::string&, const std::string&, const std::string&)", file=0x839350a
"exporter.C", line=322) at boost.C:56
#5  0x080e8e6a in ExportData::addExternalFile (this=0x94626e0,
[EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED]) at exporter.C:322
#6  0x081ee909 in InsetGraphics::prepareFile (this=0x95da380, [EMAIL PROTECTED],
   [EMAIL PROTECTED]) at insetgraphics.C:700
#7  0x081ef373 in InsetGraphics::latex (this=0x95da380,
[EMAIL PROTECTED], [EMAIL PROTECTED],
   [EMAIL PROTECTED]) at insetgraphics.C:799
#8  0x08152339 in Paragraph::Pimpl::simpleTeXSpecialChars
(this=0x95da128, [EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
   [EMAIL PROTECTED], c=1 '\001') at paragraph_pimpl.C:582
#9  0x08149fa4 in Paragraph::simpleTeXOnePar (this=0x95da1e8, [EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED],
   [EMAIL PROTECTED]) at paragraph.C:1017
#10 0x081442ab in (anonymous namespace)::TeXOnePar ([EMAIL PROTECTED],
[EMAIL PROTECTED], pit=
 {_M_node = 0x95da1e0}, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED],
   [EMAIL PROTECTED]) at output_latex.C:337
#11 0x08144dd4 in latexParagraphs ([EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
at output_latex.C:512
#12 0x08206a0f in InsetText::latex (this=0x95d9f20, [EMAIL PROTECTED],
[EMAIL PROTECTED],
   [EMAIL PROTECTED]) at insettext.C:287
---Type  to continue, or q  to quit---q

Attached is the offending lyx file.

Bo


try.lyx
Description: Binary data

Re: 1.4.2svn crash with view->postscript/dvi (export to latex?)

[Bo Peng]

The problem is at line 683, insetgraphics.C

// source file is now full path
/tmp/lyx_tmpdir20237FyBZGA/lyx_tmpbuf0/4_home_bpeng_simuPOP_doc_log_LDdecay.eps

if (!runparams.nice && GetExtension(temp_file) != ext) {
// The LaTeX compiler will not be able to determine
// the file format from the extension, so we must
// change it.
string const new_file = ChangeExtension(temp_file, ext);
// change extension to
/tmp/lyx_tmpdir20237FyBZGA/lyx_tmpbuf0/4_home_bpeng_simuPOP_doc_log_LDdecay.ps

if (lyx::support::rename(temp_file, new_file)) {
temp_file = new_file;
output_file = ChangeExtension(output_file, ext);
source_file = ChangeExtension(output_file, ext);
// source_file is no longer full path name, since output_file is not full path
} else
lyxerr[Debug::GRAPHICS]
<< "Could not rename file `"
<< temp_file << "' to `" << new_file
<< "'." << endl;
}
// The extension of temp_file might be != ext!
// source file is no longer full path name
runparams.exportdata->addExternalFile(tex_format, source_file,
  output_file);


OK, the problem is then turned to line 606,

string output_file = os::external_path(runparams.nice ?
params().filename.outputFilename(m_buffer->filePath()) :
OnlyFilename(temp_file));

Obviously, the OnlyFilename() call is in doubt here. I do not know why
it is used, when I remove it, the crash stops.

Bo

Re: export to latex

[Jean-Marc Lasgouttes]

 Edwin == Edwin Leuven [EMAIL PROTECTED] writes:

Edwin an old annoyance of mine is the following: when exporting to
Edwin latex, each cell of a table is on its own line.

Edwin with the attached each row is on its own line which i find much
Edwin better.

What would be good is to insert a \n only if the line is already too
long. But we do not have this information at this point, do we?

JMarc

Re: export to latex

[Jean-Marc Lasgouttes]

> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:

Edwin> an old annoyance of mine is the following: when exporting to
Edwin> latex, each cell of a table is on its own line.

Edwin> with the attached each row is on its own line which i find much
Edwin> better.

What would be good is to insert a \n only if the line is already too
long. But we do not have this information at this point, do we?

JMarc

export to latex

[Edwin Leuven]

an old annoyance of mine is the following:

when exporting to latex, each cell of a table is on its own line.

with the attached each row is on its own line which i find much better.

opinions (flames)?

thanks, ed.


Index: src/tabular.C
===
--- src/tabular.C   (revision 13787)
+++ src/tabular.C   (working copy)
@@ -2034,7 +2034,7 @@
 
ret += TeXCellPostamble(os, cell);
if (!isLastCellInRow(cell)) { // not last cell in row
-   os  \n;
+   os;
++ret;
}
++cell;

export to latex

[Edwin Leuven]

an old annoyance of mine is the following:

when exporting to latex, each cell of a table is on its own line.

with the attached each row is on its own line which i find much better.

opinions (flames)?

thanks, ed.


Index: src/tabular.C
===
--- src/tabular.C   (revision 13787)
+++ src/tabular.C   (working copy)
@@ -2034,7 +2034,7 @@
 
ret += TeXCellPostamble(os, cell);
if (!isLastCellInRow(cell)) { // not last cell in row
-   os << "&\n";
+   os << " & ";
++ret;
}
++cell;

diff between 'view postscript' and 'export to latex'

[JeeBee]

If I try to 'view postscript', I get some error. To see probably goes
wrong, I dived into /tmp/lyx_tmpdir22544Ij6u7P/lyx_tmpbuf0 - I guess
the directory where the temporary files are copied into.

Running LaTeX there, I get the same error as from within lyx:
! Font U/AnnSton/xl/n/24.88=AnnSton at 24.88pt not loadable: Metric (TFM)
file not found.

Now, the AnnSton.tfm was in the same directory as the .lyx file, but not
copied to the /tmp folder.

When I export .lyx to .tex and run latex on it, all works fine.

Is this a bug? Or should I more cleanly install this font (and how?)
Is there a way I can tell LyX it should also copy this file?

Thanks in advance.
JeeBee.

diff between 'view postscript' and 'export to latex'

[JeeBee]

If I try to 'view postscript', I get some error. To see probably goes
wrong, I dived into /tmp/lyx_tmpdir22544Ij6u7P/lyx_tmpbuf0 - I guess
the directory where the temporary files are copied into.

Running LaTeX there, I get the same error as from within lyx:
! Font U/AnnSton/xl/n/24.88=AnnSton at 24.88pt not loadable: Metric (TFM)
file not found.

Now, the AnnSton.tfm was in the same directory as the .lyx file, but not
copied to the /tmp folder.

When I export .lyx to .tex and run latex on it, all works fine.

Is this a bug? Or should I more cleanly install this font (and how?)
Is there a way I can tell LyX it should also copy this file?

Thanks in advance.
JeeBee.

Re: [Patch] RFQ: ParagraphList Rewrite (possible hidden bug in export to latex)

[Abdelrazak Younes]

Hello,

For those interested, here is a second version of the it_vector class. 
With former one an assertion is triggered whenever you try to export to 
latex. It seems that the at() method is used beyond the size() limit. I 
am really not sure but there is maybe a hidden bug somewhere in the 
export to latex functionality. I see a lot of boost::next inside 
output_latex.C there's maybe one that goes beyond the edges. This is 
just a guess.
This new version accept the call to at(i) with i=size() but this is only 
temporary in order to let the export working:


inline value_type  at(size_t pos) {
if (pos = ItVector_.size()) {
lyxerr[Debug::ACTION]
  trying to access element   pos
   while size is  size()  endl;
return *ItVector_[size()-1];
}
BOOST_ASSERT(pos  ItVector_.size());
return *ItVector_[pos];
}

Abdel.


Abdelrazak Younes a écrit :

Dear lyx developers,

Please find attached to this mail my refined patch for the ParagraphList 
rewrite problem. This patch makes ParagraphList derive from 
it_vectorstd::listParagraph 

it_vector is a new template class that implement the vector alike
container. It is defined in it_vector.h. I don't know how to make a
patch that add a new file so this file is attached to this mail. If you
think of a better name, please let me know.

This patch brings a straight forward replacement for ParagraphList 
requiring no other change to current source code as required by Lars. I 
mean _zero_ change :-)
I know that lars wanted a cpp only implementation but I think that by 
making use of forward declaration of ParagraphList we can avoid to 
rebuild the whole tree in case we want to modify it_vector; only those 
cpp that works with ParagraphList directly (I know they are quite a few 
but that is acceptable IMHO). In any case, playing with the inner 
container will need a header change.


You could see it_vector as a proposal for the interface we where 
taking about: vector alike (i.e. operator[] access) _plus_ 
vector::iterator access. I have covered all practical cases, at least 
those used in current source code. I have added some useful interfaces 
(ex: position access method, for_each methods that use a functor as an
argument, etc), we can add other methods later (or remove some) if this 
first iteration is agreed upon developer.


I would like to emphasize that it_vector class is _my_ view of it. You 
are of course free to use it, modify it or replace it with whatever 
implementation you'd like to try that you think is more powerful. I just 
hope that you retain the interface I am proposing in it_vector. I have 
tested it only with listParagraph as the template argument so I am 
sure it will work for any kind of container... but it should. IMHO this 
implementation is fast enough, and there are much worse performance 
problem to solve.


This patch is not yet ready because CutPaste and CopyPaste don't work 
but I prefer to send it now for review. Plus I am not sure whether the 
bug is in ParagraphList or in my Qt4 frontend clipboard support. It 
seems that what is copied in the selection is rubbish. I can see that 
when I copy select something inside the paragraph and then paste it 
elsewhere, weird characters are pasted that do not correspond to the 
copied ones. I tried to analyze LFUN_COPY but I got lost in LCursor, 
dociterator and company... :-(

Someone could tell me where the text copying effectively take place?

Provided that you accept this patch, or at least that you retain the 
interface, here is my TODO list concerning this ParagraphList thing:


1) Fix the Copy bug. This one is really difficult...

2) Try to reduce the time of rebuilding the tree in case of a change in 
it_vector.h. A priori, the main limiting factor is that LyxText.h is 
included at many place in the code.


3) simplify the use of ParagraphList wherever possible by using
some of the convenience interface methods in it_vector (my original
patch did some simplifications already).

4) Rename ParagraphList into paragraph_container.

5) Transform some functions that uses ParagraphList into ParagraphList 
member methods (in particular those in paragraph_func.C) or at least 
create helper method for classes that uses ParagraphList (Undo, 
CutAndPaste, etc).


6) See if some other classes can benefit from it_vector (InsetList and 
FontList come to mind).


Abdel.





Index: ParagraphList_fwd.h
===
RCS file: /var/cvs/lyx/lyx-devel/src/ParagraphList_fwd.h,v
retrieving revision 1.4
diff -u -r1.4 ParagraphList_fwd.h
--- ParagraphList_fwd.h 16 Nov 2004 20:41:37 -  1.4
+++ ParagraphList_fwd.h 11 Feb 2006 19:58:48 -
@@ -7,27 +7,38 @@
  * \author Angus Leeming
  *
  * Full author contact details are available in file CREDITS.
+ *
+ * \todo Rename

Re: [Patch] RFQ: ParagraphList Rewrite (possible hidden bug in export to latex)

[Abdelrazak Younes]

Hello,

For those interested, here is a second version of the it_vector class. 
With former one an assertion is triggered whenever you try to export to 
latex. It seems that the at() method is used beyond the size() limit. I 
am really not sure but there is maybe a hidden bug somewhere in the 
"export to latex" functionality. I see a lot of "boost::next" inside 
output_latex.C there's maybe one that goes beyond the edges. This is 
just a guess.
This new version accept the call to at(i) with i=size() but this is only 
temporary in order to let the export working:


inline value_type & at(size_t pos) {
if (pos >= ItVector_.size()) {
lyxerr[Debug::ACTION]
 << "trying to access element " << pos
 << " while size is "<< size() << endl;
return *ItVector_[size()-1];
}
BOOST_ASSERT(pos < ItVector_.size());
return *ItVector_[pos];
}

Abdel.


Abdelrazak Younes a écrit :

Dear lyx developers,

Please find attached to this mail my refined patch for the ParagraphList 
rewrite problem. This patch makes "ParagraphList" derive from 
"it_vector<std::list >"

"it_vector" is a new template class that implement the vector alike
container. It is defined in "it_vector.h". I don't know how to make a
patch that add a new file so this file is attached to this mail. If you
think of a better name, please let me know.

This patch brings a straight forward replacement for ParagraphList 
requiring no other change to current source code as required by Lars. I 
mean _zero_ change :-)
I know that lars wanted a cpp only implementation but I think that by 
making use of forward declaration of ParagraphList we can avoid to 
rebuild the whole tree in case we want to modify it_vector; only those 
cpp that works with ParagraphList directly (I know they are quite a few 
but that is acceptable IMHO). In any case, playing with the inner 
container will need a header change.


You could see "it_vector" as a proposal for the interface we where 
taking about: "vector alike" (i.e. operator[] access) _plus_ 
vector::iterator access. I have covered all practical cases, at least 
those used in current source code. I have added some useful interfaces 
(ex: position access method, "for_each" methods that use a functor as an
argument, etc), we can add other methods later (or remove some) if this 
first iteration is agreed upon developer.


I would like to emphasize that "it_vector" class is _my_ view of it. You 
are of course free to use it, modify it or replace it with whatever 
implementation you'd like to try that you think is more powerful. I just 
hope that you retain the interface I am proposing in "it_vector". I have 
tested it only with "list" as the template argument so I am 
sure it will work for any kind of container... but it should. IMHO this 
implementation is fast enough, and there are much worse performance 
problem to solve.


This patch is not yet ready because Cut and Copy don't work 
but I prefer to send it now for review. Plus I am not sure whether the 
bug is in ParagraphList or in my Qt4 frontend clipboard support. It 
seems that what is copied in the selection is rubbish. I can see that 
when I copy select something inside the paragraph and then paste it 
elsewhere, weird characters are pasted that do not correspond to the 
copied ones. I tried to analyze LFUN_COPY but I got lost in "LCursor", 
"dociterator" and company... :-(

Someone could tell me where the text copying effectively take place?

Provided that you accept this patch, or at least that you retain the 
interface, here is my TODO list concerning this ParagraphList thing:


1) Fix the Copy bug. This one is really difficult...

2) Try to reduce the time of rebuilding the tree in case of a change in 
"it_vector.h". A priori, the main limiting factor is that "LyxText.h" is 
included at many place in the code.


3) simplify the use of ParagraphList wherever possible by using
some of the convenience interface methods in it_vector (my original
patch did some simplifications already).

4) Rename ParagraphList into paragraph_container.

5) Transform some functions that uses ParagraphList into ParagraphList 
member methods (in particular those in paragraph_func.C) or at least 
create helper method for classes that uses ParagraphList (Undo, 
CutAndPaste, etc).


6) See if some other classes can benefit from it_vector (InsetList and 
FontList come to mind).


Abdel.





Index: ParagraphList_fwd.h
===
RCS file: /var/cvs/lyx/lyx-devel/src/ParagraphList_fwd.h,v
retrieving revision 1.4
diff -u -r1.4 ParagraphList_

LyX export to latex broken

[Angus Leeming]

This smacks of Boost.Filesystem breakage.

qlyxcvs is a symbolic link pointing at ~/lyx/devel/build/src/lyx-qt

$ qlyxcvs -e latex UserGuide_13x.lyx
LyXTextClassList::Read: unable to find textclass file  `'. Exiting.

$ ~/lyx/devel/build/src/lyx-qt -e latex UserGuide_13x.lyx
creating local macro macro
creating local macro macrowarg

-- 
Angus

Re: LyX export to latex broken

[Angus Leeming]

Angus Leeming wrote:

 This smacks of Boost.Filesystem breakage.
 qlyxcvs is a symbolic link pointing at ~/lyx/devel/build/src/lyx-qt
 $ qlyxcvs -e latex UserGuide_13x.lyx
 LyXTextClassList::Read: unable to find textclass file  `'. Exiting.

This was my bad. I had a ~/lib/lyxrc.defaults file left around from my
testing of the packaging stuff. Messes up build_support...
 
package
binary_dir /home/angus/bin/
system_support /home/angus/lyx/devel/lib/
build_support /home/angus/lib/
user_support /home/angus/.lyx-1.4.0cvs/
locale_dir
document_dir /home/angus
temp_dir /tmp
home_dir /home/angus
/package

-- 
Angus

LyX export to latex broken

[Angus Leeming]

This smacks of Boost.Filesystem breakage.

qlyxcvs is a symbolic link pointing at ~/lyx/devel/build/src/lyx-qt

$ qlyxcvs -e latex UserGuide_13x.lyx
LyXTextClassList::Read: unable to find textclass file  `'. Exiting.

$ ~/lyx/devel/build/src/lyx-qt -e latex UserGuide_13x.lyx
creating local macro macro
creating local macro macrowarg

-- 
Angus

Re: LyX export to latex broken

[Angus Leeming]

Angus Leeming wrote:

> This smacks of Boost.Filesystem breakage.
> qlyxcvs is a symbolic link pointing at ~/lyx/devel/build/src/lyx-qt
> $ qlyxcvs -e latex UserGuide_13x.lyx
> LyXTextClassList::Read: unable to find textclass file  `'. Exiting.

This was my bad. I had a ~/lib/lyxrc.defaults file left around from my
testing of the packaging stuff. Messes up build_support...
 

binary_dir /home/angus/bin/
system_support /home/angus/lyx/devel/lib/
build_support /home/angus/lib/
user_support /home/angus/.lyx-1.4.0cvs/
locale_dir
document_dir /home/angus
temp_dir /tmp
home_dir /home/angus


-- 
Angus

Re: command to export to latex ?

[John Levon]

On Tue, Feb 19, 2002 at 07:43:30PM +0100, Toni Moreno Giménez wrote:

 I'm automatizing documentacion creation and web updating process, by using 
 bash scripting ,from LyX based documents, but I need a command to export 
 *.lyx to *.tex . without needed of use the LyX GUI.

You can use -i and -e options on lyx command line to do this.

regards
john

p.s. your question would have been better on lyx-users


-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: command to export to latex ?

[John Levon]

On Tue, Feb 19, 2002 at 07:43:30PM +0100, Toni Moreno Giménez wrote:

> I'm automatizing documentacion creation and web updating process, by using 
> bash scripting ,from LyX based documents, but I need a command to export 
> *.lyx to *.tex . without needed of use the LyX GUI.

You can use -i and -e options on lyx command line to do this.

regards
john

p.s. your question would have been better on lyx-users


-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

command to export to latex ?

[Toni Moreno Giménez]

Hay , Im not subscribed to the list, please , send me directly to me, your 
answers , thanks.

I'm automatizing documentacion creation and web updating process, by using 
bash scripting ,from LyX based documents, but I need a command to export 
*.lyx to *.tex . without needed of use the LyX GUI.

How can I do it ?

Lots Of Thanks
-- 
=
Toni Moreno Giménez
=
Pje de las rosas  nº 22
Vilassar de Mar 
(Barcelona) España
CP: 08340

Re: command to export to latex ?

[Vitaly Lipatov]

On 19 February 2002 21:43, Toni Moreno Giménez wrote:
 Hay , Im not subscribed to the list, please , send me directly to me, your
 answers , thanks.

 I'm automatizing documentacion creation and web updating process, by using
 bash scripting ,from LyX based documents, but I need a command to export
 *.lyx to *.tex . without needed of use the LyX GUI.

 How can I do it ?

 Lots Of Thanks
lyx --help

-- 
Lav

GNU! Linux! LaTeX! LyX!