Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 10:14:23PM +0100, Guillaume M-M wrote:
 Le 01/06/2015 21:16, Guillaume M-M a écrit :
 
 Anyway, here's a suggestion for getting those horrible bitmap fonts out
 of the way of new users, in a perfectly non-intrusive and
 backwards-compatible manner: just set Latin Modern to be the default
 choice for a new document. This would also solve the issue considered
 above. Note that I don't suggest to change the meaning of Default for
 roman fonts, but rather to force the user explicitly select Default
 over Latin Modern if he really wants to. I think it is always good
 when LyX shows the standard way. Then if the user wants poor bitmap
 fonts, that will be by choice.
 
 
 I am aware that it is less simple than it sounds given that often the user
 wants to switch to a document class that already has more sensible defaults.
 I will open an enhancement request if I figure out a solution, but I'd be
 happy to know whether something like this was already discussed on the list.

Many times...

-- 
Enrico

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> 
> In fact it does not work entirely in master. There is a regression (after
> bc47054b I believe) because compilation can now fail due to \renewcommandx
> being used without the command being defined prior to that (try the attached
> lyx-bug-renewcommandx.lyx). (Stable is fine in this regard after your commit
> 9285f338, it seems.) 
> 
> One quick solution would be to prepend all \renewcommandx\a{b} with
> \providecommand\a{}.

I think this was already addressed by Jürgen at 83a9ed4e.

> Here are other conclusions from my test of stable and master this week-end:
> 
> 1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See the
> attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py now
> includes the font lmodern (L236). I do not understand this addition: font
> setting is already done in the preamble. Removing the line fixes the issue.

It was added in order to have vector fonts, otherwise the previews
generated by the legacy method would be of very poor quality. It is
difficult to determine what a user could do in the preamble and whether
it is safe using lmodern or not. However, given that it may produce issues,
it may be better not using it, if nobody has a better idea.

> 2) In master, preview incorrectly calls latex instead of pdflatex if the
> default output format is set to "default". More details in the attached
> lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the
> "default" (pdflatex) compilation with Ctrl+R succeeds.)
> Stable also fails because it seems to call latex instead of pdflatex all the
> time, but it does not appear to be a regression wrt 2.1.3.

Note that we have to guarantee backward compatibility and using latex
when the document does not specify a default output format is a must,
otherwise instant preview may fail for existing documents.
See #9371 for details.

When using pdflatex (or other formats producing a pdf) for generating
the previews, the legacy method is used. It turns out to be much slower
than the dvipng route, so that care is taken to try to use dvi output for
all previews not failing and then trying pdflatex for those that fail.
For some reason, the failure you report escapes those checks. So, this
reason should be identified and accordingly corrected. Typically, in
open source projects one can suggest a patch to speed up the correction
of an issue.

> 3) As reported in #6369, "InstantPreview multiplies math macros
> definitions". Although the particular compilation issue has been solved, the
> duplication of macro definitions is not fixed. This has performance
> consequences. In stable and master, opening a moderately-sized math article
> (10-20 pages) with instant preview activated results in 75s of full CPU
> usage (and more when latex is called incorrectly instead of pdflatex), 55s
> during which LyX is unresponsive (and just generates the tex file). The
> instant preview tex file is 55 lines long and is 16MB big, mainly
> comprised of macro definitions (maybe there is another performance
> bottleneck, but this is probably one). So instant preview is still unusable
> for me (at least until the instant preview inset supports math macros---BTW
> the patch  works
> well for me).

This is not my experience. Instant preview snippets for the math manual
(which surely qualifies as a medium-sized math article) are generated in
about 10 seconds on my old and slow laptop and the instant preview tex
file is about 50Kb.

> 4) Using Ctrl+Mousewheel to zoom sometimes results in a preview of the wrong
> size. LyX recreates the previews when zooming, and sometimes we end up with
> an intermediary size of preview inconsistent with the size of the text (race
> condition?).

The previous are generated asynchronously, thus, if you change the zoom while
they are still being generated, you may end up with different sizes. This
can be improved, of course. Maybe using Ctrl+Mousewheel may generate
multiple sizes at once and this causes that issue. Try using the Alt+ and
Alt- shortcuts (and wait for the previews to be generated before using
them again).

> (BTW why redoing preview from scratch when the pdf is already generated? Why
> not keeping the each preview as a pdfs, displayed on the fly by LyX using
> Cairo, when actually needed? This sounds vastly more efficient.)

There is the problem of assuring that the previews are still the same and
not actually changed. ATM there is no way to trigger a different way for
the regeneration due to zooming. Also in this case, I think that a patch
would be thoughtfully considered, but I doubt it can lead to a significant
speed up, as the most part of the time is spent in converting the pdfs
rather than regenerating them.

> 3+4) Zooming with Ctrl+mousewheel is impossible with instant preview
> activated in a reasonably-sized document 

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
> On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> > 
> > 2) In master, preview incorrectly calls latex instead of pdflatex if the
> > default output format is set to "default". More details in the attached
> > lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the
> > "default" (pdflatex) compilation with Ctrl+R succeeds.)
> > Stable also fails because it seems to call latex instead of pdflatex all the
> > time, but it does not appear to be a regression wrt 2.1.3.
> 
> Note that we have to guarantee backward compatibility and using latex
> when the document does not specify a default output format is a must,
> otherwise instant preview may fail for existing documents.
> See #9371 for details.
> 
> When using pdflatex (or other formats producing a pdf) for generating
> the previews, the legacy method is used. It turns out to be much slower
> than the dvipng route, so that care is taken to try to use dvi output for
> all previews not failing and then trying pdflatex for those that fail.
> For some reason, the failure you report escapes those checks. So, this
> reason should be identified and accordingly corrected. Typically, in
> open source projects one can suggest a patch to speed up the correction
> of an issue.

I had a closer look at this issue and it turned out to be as follows.
If a snippet produces latex errors it is now not previewed at all.
Now, when using the microtype package in dvi mode, latex issues an
error about not finding the tfm file for a font, but nevertheless
goes on and produces a correct output. This error is issued only at
the beginning so that it associated with the first snippet, which is
for this reason marked as bad. Actually, the script generates a valid
preview but it is not used. All other snippets are used, so only the
first one is omitted even if it would be Ok.

There are 2 possible solutions. The first one is omitting the microtype
package for the sake of generating the previews by using the faster
dvipng method (attached patch no-microtype.diff for master).
The second one is forcing the use of pdflatex when the use of microtype
is detected. In this case the slower legacy mathod will be used for
generating the previews (attached patch yes-microtype.diff for master).

Please, vote for the one or the other. I will commit the patch getting
more votes.

I also noticed that when microtype is used in dvi mode latex takes a
lot more of time to process the same file. Maybe this is the cause of
the slowdown observed by Guillaume.

-- 
Enrico
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 5eca959..9d46054 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -160,11 +160,17 @@ def extract_metrics_info(dvipng_stdout):
 
 def fix_latex_file(latex_file):
 documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
+microtype_re = re.compile("usepackage.*\{microtype\}")
 
 tmp = mkstemp()
 
 changed = 0
 for line in open(latex_file, 'r').readlines():
+match = microtype_re.match(line)
+if match != None:
+changed = 1
+continue
+
 match = documentclass_re.match(line)
 if match == None:
 tmp.write(line)
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 5eca959..3aec16f 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -160,11 +160,17 @@ def extract_metrics_info(dvipng_stdout):
 
 def fix_latex_file(latex_file):
 documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
+microtype_re = re.compile("usepackage.*\{microtype\}")
 
 tmp = mkstemp()
 
+force_pdf_output = 0
 changed = 0
 for line in open(latex_file, 'r').readlines():
+match = microtype_re.match(line)
+if match != None:
+force_pdf_output = 1
+
 match = documentclass_re.match(line)
 if match == None:
 tmp.write(line)
@@ -176,7 +182,7 @@ def fix_latex_file(latex_file):
 if changed:
 copyfileobj(tmp, open(latex_file,"wb"), 1)
 
-return changed
+return force_pdf_output
 
 
 def convert_to_ppm_format(pngtopnm, basename):
@@ -384,6 +390,12 @@ def main(argv):
 # These flavors of latex are known to produce pdf output
 pdf_output = latex in pdflatex_commands
 
+# Omit font size specification in latex file.
+force_pdf_output = fix_latex_file(latex_file)
+if force_pdf_output and not pdf_output:
+pdf_output = True
+latex = "pdflatex"
+
 progress("Latex command: %s" % latex)
 progress("Latex produces pdf output: %s" % pdf_output)
 progress("Bib

Re: test of math previews (was: [LyX/master] Really fix bug #9354)

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
> On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> > 
> > 1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See the
> > attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py now
> > includes the font lmodern (L236). I do not understand this addition: font
> > setting is already done in the preamble. Removing the line fixes the issue.
> 
> It was added in order to have vector fonts, otherwise the previews
> generated by the legacy method would be of very poor quality. It is
> difficult to determine what a user could do in the preamble and whether
> it is safe using lmodern or not. However, given that it may produce issues,
> it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?

-- 
Enrico

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:

> I don't understand the
> backwards-compatibility argument here, I think that it is safer to use the
> same default format as Ctrl+R in all cases.

I think that the backward-compatibility argument is a serious one.
If an old document that was perfectly working does not work anymore,
one could simply decide that LyX is not the right tool to use and it
is safer using latex directly.

-- 
Enrico

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 09:16:00PM +0100, Guillaume M-M wrote:
> 
> Is there any lyx file demonstrating the poor font quality? I have been
> unable to reproduce the font issue in master (after removing the line that
> forces latin modern in instant previews), even with the default setting of
> LyX that produces a PDF with bitmap fonts...

I attach here the pdfs I get with a new document with default output set to
pdflatex and simply an 'a' in a preview inset.
The first one (lyxpreviewdCv436.pdf) when I ditch the lmodern line, the
second one (lyxpreviewxWL436.pdf) with that line in place. The previews
are then generated by converting the pdfs into pngs.
Here you can also find how the difference looks like on screen:
http://www.lyx.org/trac/attachment/ticket/9371/example-2.1.png (good)
http://www.lyx.org/trac/attachment/ticket/9371/example-2.2.png (bad)

-- 
Enrico


lyxpreviewdCv436.pdf
Description: Adobe PDF document


lyxpreviewxWL436.pdf
Description: Adobe PDF document

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:
> 
> IF the inconsistency regarding the meaning of "Default output format:
> Default" is intended for performance reason and that I did not make you
> change your mind, then I vote for:
> > omitting the microtype
> > package for the sake of generating the previews by using the faster
> > dvipng method

Ok, noted.

> But again it is hard to guess that "default output format: default" has this
> optimisation while "default output format: PDF (pdflatex)" does not. (But at
> least there is the option to force the use of pdflatex by instant preview if
> really needed.)

While in principle I agree that generating the previews with the same
engine is the right thing to do, there is the problem that dvipng is
really fast while generating pngs from pdfs is much slower. If you take
away pdftocairo and then try the legacy route, you will see that it is
about 10 times slower. With pdftocairo it is only about 3 times slower.
If you are concerned about speed, I see no other way to allow a decent
implementation of instant previews.

> By the way, a safer way to force not loading a package is to prepend
> \usepackage with "\@namedef{v...@microtype.sty}{/12/31}". If you just
> strip the line from the preamble you can easily run into troubles. In
> addition, at some point I had it on two lines like this (note the %):
>   \usepackage[protrusion=true%,expansion=false
>   ]{microtype}
> in which case your regexp fails if I understood correctly. I suggest just
> adding "\@namedef{v...@microtype.sty}{/12/31}" before the preamble
> whether we suspect that microtype is used or not, without testing for its
> presence. (Unless you see other errors this might generate.)

Ok, thanks for the tip.

> Again the philosophy of my comment is not "please deal explicitly with these
> corner cases" but "it's better to take the safe route".

But you show a problem with a corner case and the safe route may be costly.

> I really like the direction of the new patches trying to make instant
> preview "just work", I hope that my tests and comments help you in this
> regard.

Yes, thank you, that's really appreciated.

> You may be right that microtype may have been the reason why I had the
> impression that latex is slower than pdflatex, but this does not account for
> the 55s (on a good computer) during which LyX is frozen while generating the
> 16MB tex file. I will run tests again to confirm (and also test the new
> patch) and will reply to the previous message in a short while. (BTW yes I
> have epstopdf and pdfcairo.)

Here we are not going anywhere. I say it works well for me, while you say it
doesn't work. Please, provide an example that generates a 16MB tex file for
a ~20 page document.

-- 
Enrico

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 11:01:48PM +0100, Guillaume M-M wrote:

> Le 01/06/2015 22:12, Enrico Forestieri a écrit :
> >On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:
> >
> >>I don't understand the
> >>backwards-compatibility argument here, I think that it is safer to use the
> >>same default format as Ctrl+R in all cases.
> >
> >I think that the backward-compatibility argument is a serious one.
> >If an old document that was perfectly working does not work anymore,
> >one could simply decide that LyX is not the right tool to use and it
> >is safer using latex directly.
> >
> 
> 
> I know the importance of backwards compatibility, but I don't understand how
> it applies here.
> 
> Currently in stable:
> * With default format output = Default
>   * Ctrl+R -> pdflatex
>   * Instant preview -> latex
> * With default format output = PDF (pdflatex)
>   * Ctrl+R -> pdflatex
>   * Instant preview -> latex
> 
> Whereas in master:
> * With default format output = Default
>   * Ctrl+R -> pdflatex
>   * Instant preview -> latex
> * With default format output = PDF (pdflatex)
>   * Ctrl+R -> pdflatex
>   * Instant preview -> pdflatex
> 
> Thus, if changing the behaviour of instant preview for "Default" means
> breaking backwards compatibility, then backwards compatibility is already
> broken in master given that the behaviour is changed for "PDF (pdflatex)".
> We don't appear to believe that. This is what I meant.

If the default output format set in the preferences is always used,
this document:
http://www.lyx.org/trac/raw-attachment/ticket/9371/pst-triangle.lyx
that previews correctly in 2.1, would fail in 2.2 if the default
output format in the preferences is set to pdflatex.
Now it can also be correctly previewed in 2.2 without explicitly setting
the default format for the document, i.e., without modifying the document.
Please, read the discussion about this topic (bug #9371).

> But I am receptive to your idea of keeping latex for the speedup and
> disabling microtype, for the same speed reason. I like the idea of still
> having the choice via "default output format" (even though the feature will
> be kind of hidden).

Please, look in the archives for the extensive discussion about this point.

-- 
Enrico

Re: test of math previews

[Enrico Forestieri]

On Mon, Jun 01, 2015 at 10:14:23PM +0100, Guillaume M-M wrote:
> Le 01/06/2015 21:16, Guillaume M-M a écrit :
> >
> >Anyway, here's a suggestion for getting those horrible bitmap fonts out
> >of the way of new users, in a perfectly non-intrusive and
> >backwards-compatible manner: just set Latin Modern to be the default
> >choice for a new document. This would also solve the issue considered
> >above. Note that I don't suggest to change the meaning of "Default" for
> >roman fonts, but rather to force the user explicitly select "Default"
> >over "Latin Modern" if he really wants to. I think it is always good
> >when LyX shows the standard way. Then if the user wants poor bitmap
> >fonts, that will be by choice.
> >
> 
> I am aware that it is less simple than it sounds given that often the user
> wants to switch to a document class that already has more sensible defaults.
> I will open an enhancement request if I figure out a solution, but I'd be
> happy to know whether something like this was already discussed on the list.

Many times...

-- 
Enrico

Re: [LyX/master] Really fix bug #9354

[Enrico Forestieri]

On Sun, May 31, 2015 at 01:24:05PM +0200, Kornel Benko wrote:

 Am Sonntag, 31. Mai 2015 um 00:53:41, schrieb Enrico Forestieri 
 for...@lyx.org
  commit ad0d0f6d69a7acd6e99f7858f08b427a28d8f8cc
  Author: Enrico Forestieri for...@lyx.org
  Date:   Sun May 31 00:52:49 2015 +0200
  
  Really fix bug #9354
  
 
 This is still not working in branch for redefined macros.
 (Works in master as implemented by Jürgen)
 
 Try the attached. (The second definition of \qG is different, but the preview
 is not changed)

Thanks, should be fixed now.
This has nothing to do with bug 9354, though.

-- 
Enrico

Re: [LyX/master] Really fix bug #9354

[Enrico Forestieri]

On Sun, May 31, 2015 at 01:24:05PM +0200, Kornel Benko wrote:

> Am Sonntag, 31. Mai 2015 um 00:53:41, schrieb Enrico Forestieri 
> <for...@lyx.org>
> > commit ad0d0f6d69a7acd6e99f7858f08b427a28d8f8cc
> > Author: Enrico Forestieri <for...@lyx.org>
> > Date:   Sun May 31 00:52:49 2015 +0200
> > 
> > Really fix bug #9354
> > 
> 
> This is still not working in branch for redefined macros.
> (Works in master as implemented by Jürgen)
> 
> Try the attached. (The second definition of \qG is different, but the preview
> is not changed)

Thanks, should be fixed now.
This has nothing to do with bug 9354, though.

-- 
Enrico

Re: LyX 2.1.4

[Enrico Forestieri]

On Sat, May 30, 2015 at 06:21:03PM +0100, Guillaume M-M wrote:

 Dear Enrico,
 
 It's quite strange, to me #9354 does not appear fixed at all! I just left a
 detailed comment in http://www.lyx.org/trac/ticket/9354.

Please, try again with latest master. The fix for stable will have to wait
the next round because it needs testing. Sorry for the false alarm.

-- 
Enrico

Re: LyX 2.1.4

[Enrico Forestieri]

On Fri, May 29, 2015 at 11:12:51AM -0400, Richard Heck wrote:

 
 I'd like to start the 2.1.4 release process by freezing strings, etc. Any
 fixes that need to go in before I do that?

What about http://www.lyx.org/trac/ticket/8258 ?

I have also attached a patch at http://www.lyx.org/trac/ticket/9371
that, by only touching the python scripts, would solve:
http://www.lyx.org/trac/ticket/6369
http://www.lyx.org/trac/ticket/9354
http://www.lyx.org/trac/ticket/9508
http://www.lyx.org/trac/ticket/9510

-- 
Enrico

Re: LyX 2.1.4

[Enrico Forestieri]

On Fri, May 29, 2015 at 11:12:51AM -0400, Richard Heck wrote:

> 
> I'd like to start the 2.1.4 release process by freezing strings, etc. Any
> fixes that need to go in before I do that?

What about http://www.lyx.org/trac/ticket/8258 ?

I have also attached a patch at http://www.lyx.org/trac/ticket/9371
that, by only touching the python scripts, would solve:
http://www.lyx.org/trac/ticket/6369
http://www.lyx.org/trac/ticket/9354
http://www.lyx.org/trac/ticket/9508
http://www.lyx.org/trac/ticket/9510

-- 
Enrico

Re: LyX 2.1.4

[Enrico Forestieri]

On Sat, May 30, 2015 at 06:21:03PM +0100, Guillaume M-M wrote:

> Dear Enrico,
> 
> It's quite strange, to me #9354 does not appear fixed at all! I just left a
> detailed comment in .

Please, try again with latest master. The fix for stable will have to wait
the next round because it needs testing. Sorry for the false alarm.

-- 
Enrico

Re: LyX banner has strange bottom line for me

[Enrico Forestieri]

On Wed, May 27, 2015 at 11:33:16AM +0200, Stephan Witt wrote:
 
 It's much better. 
 
 But I think it looks a little bit aggressive.

Uh?

 Is it possible to make the background look like a
 page turning book? This makes sense with LyX, IMHO.

I don't understand. It's already like that.

-- 
Enrico

Re: LyX banner has strange bottom line for me

[Enrico Forestieri]

On Wed, May 27, 2015 at 12:11:59PM +0200, Jean-Marc Lasgouttes wrote:
 
 It looks good. Do we have some provision for localization?

The only way would be omitting the text (paths, actually) and
superimposing a translation as we do for the version info.

 Do we want to?

Don't know. I would say no as it is like a brand.

-- 
Enrico

Re: LyX banner has strange bottom line for me

[Enrico Forestieri]

On Wed, May 27, 2015 at 12:41:39PM +0200, Stephan Witt wrote:
 Am 27.05.2015 um 12:31 schrieb Stephan Witt st.w...@gmx.net:
 
  Am 27.05.2015 um 12:12 schrieb Enrico Forestieri for...@lyx.org:
  
  On Wed, May 27, 2015 at 11:33:16AM +0200, Stephan Witt wrote:
  
  It's much better. 
  
  But I think it looks a little bit aggressive.
  
  Uh?
  
  Sorry, it's only me, perhaps.
  
  Is it possible to make the background look like a
  page turning book? This makes sense with LyX, IMHO.
  
  I don't understand. It's already like that.
  
  Yes, that's why I had the idea. I meant to add some lines 
  of text to the pages if possible.
 
 Or something that makes the impression of text lines...

I fear that would simply clutter the image (and much work to obtain).

 I just opened the SVG with inkscape and noticed some difference
 with the frames. The shadow of the SVG is not drawn in LyX.
 And the shadow of the letters of the LyX logo is missing too.
 Probably the SVG renderer of Qt isn't perfect.

It seems the blur effect is not rendered and thus the shadows disappear
altogether. I tried to force their rendering (see attached), but in
LyX the shadow boundaries appear to be too sharp (compare the same image
loaded with inkscape).

-- 
Enrico

Re: LyX banner has strange bottom line for me

[Enrico Forestieri]

On Tue, May 26, 2015 at 07:34:35AM -0400, Scott Kostyshak wrote:
 Attached is a screenshot of how the LyX banner looks for me on Ubuntu
 with Qt 5.5dev.

What about the attached one?

-- 
Enrico

Re: LyX banner has strange bottom line for me

[Enrico Forestieri]

On Tue, May 26, 2015 at 07:34:35AM -0400, Scott Kostyshak wrote:
> Attached is a screenshot of how the LyX banner looks for me on Ubuntu
> with Qt 5.5dev.

What about the attached one?

-- 
Enrico

Re: LyX banner has strange bottom line for me

[Enrico Forestieri]

On Wed, May 27, 2015 at 11:33:16AM +0200, Stephan Witt wrote:
> 
> It's much better. 
> 
> But I think it looks a little bit aggressive.

Uh?

> Is it possible to make the "background" look like a
> "page turning book"? This makes sense with LyX, IMHO.

I don't understand. It's already like that.

-- 
Enrico

Re: LyX banner has strange bottom line for me

[Enrico Forestieri]

On Wed, May 27, 2015 at 12:11:59PM +0200, Jean-Marc Lasgouttes wrote:
> 
> It looks good. Do we have some provision for localization?

The only way would be omitting the text (paths, actually) and
superimposing a translation as we do for the version info.

> Do we want to?

Don't know. I would say no as it is like a brand.

-- 
Enrico

Re: LyX banner has strange bottom line for me

[Enrico Forestieri]

On Wed, May 27, 2015 at 12:41:39PM +0200, Stephan Witt wrote:
> Am 27.05.2015 um 12:31 schrieb Stephan Witt <st.w...@gmx.net>:
> 
> > Am 27.05.2015 um 12:12 schrieb Enrico Forestieri <for...@lyx.org>:
> > 
> >> On Wed, May 27, 2015 at 11:33:16AM +0200, Stephan Witt wrote:
> >>> 
> >>> It's much better. 
> >>> 
> >>> But I think it looks a little bit aggressive.
> >> 
> >> Uh?
> > 
> > Sorry, it's only me, perhaps.
> > 
> >>> Is it possible to make the "background" look like a
> >>> "page turning book"? This makes sense with LyX, IMHO.
> >> 
> >> I don't understand. It's already like that.
> > 
> > Yes, that's why I had the idea. I meant to add some lines 
> > of text to the pages if possible.
> 
> Or something that makes the impression of text lines...

I fear that would simply clutter the image (and much work to obtain).

> I just opened the SVG with inkscape and noticed some difference
> with the frames. The shadow of the SVG is not drawn in LyX.
> And the shadow of the letters of the LyX logo is missing too.
> Probably the SVG renderer of Qt isn't perfect.

It seems the blur effect is not rendered and thus the shadows disappear
altogether. I tried to force their rendering (see attached), but in
LyX the shadow boundaries appear to be too sharp (compare the same image
loaded with inkscape).

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 25, 2015 at 03:19:00PM +0200, Stephan Witt wrote:
  
  Stephan, please can you check whether the attached patch works on Mac?
  For testing it, as an example, first save lib/examples/thesis/thesis.lyx
  in the current format (this is important) and then install LyX as you
  usually do with autotools. After that, move your application directory
  around and manually copy thesis.lyx somewhere else. I think you should do
  something like:
  $ cp /path/to/LyXappdir/examples/thesis/thesis.lyx /your/homedir/thesis.lyx
  
  Then try loading the copied file:
  $ /path/to/LyXappdir/bin/lyx /your/homedir/thesis.lyx
  
  If it works, all included files should be found. A quick way to check
  that is trying to typeset the document. It works if you don't get errors.
 
 Yes, it works.
 But I'm not sure if this scenario (the copying step) is a real one.

I think it is. I see that thesis.lyx is now in examples but I think that
it was in templates previously. Moving it back to templates, you could do
New from Template, choose thesis.lyx and it would work.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 25, 2015 at 03:19:00PM +0200, Stephan Witt wrote:
> > 
> > Stephan, please can you check whether the attached patch works on Mac?
> > For testing it, as an example, first save lib/examples/thesis/thesis.lyx
> > in the current format (this is important) and then install LyX as you
> > usually do with autotools. After that, move your application directory
> > around and manually copy thesis.lyx somewhere else. I think you should do
> > something like:
> > $ cp /path/to/LyXappdir/examples/thesis/thesis.lyx /your/homedir/thesis.lyx
> > 
> > Then try loading the copied file:
> > $ /path/to/LyXappdir/bin/lyx /your/homedir/thesis.lyx
> > 
> > If it works, all included files should be found. A quick way to check
> > that is trying to typeset the document. It works if you don't get errors.
> 
> Yes, it works.
> But I'm not sure if this scenario (the copying step) is a real one.

I think it is. I see that thesis.lyx is now in examples but I think that
it was in templates previously. Moving it back to templates, you could do
"New from Template", choose thesis.lyx and it would work.

-- 
Enrico

Re: [LyX/master] Set the origin tag to the proper directory at install time.

[Enrico Forestieri]

On Sun, May 24, 2015 at 11:21:50AM +0200, Kornel Benko wrote:

 Am Sonntag, 24. Mai 2015 um 01:24:42, schrieb Enrico Forestieri 
 for...@lyx.org
  commit 7c48bb0208fac84155a83d2f24041dd0c9198776
  Author: Enrico Forestieri for...@lyx.org
  Date:   Sun May 24 01:13:41 2015 +0200
  
  Set the origin tag to the proper directory at install time.
  
 
 I prefer that the origin flag in lyx-files in the repository
 be set to unavailable.

By default, it will be after 260a98d2.

 ATM there are some unwanted entries.
   # find . -name \*.lyx | xargs egrep '\\origin' | egrep -v 
 '(roundtrip|unavailable)'
   ./lib/doc/Customization.lyx:\origin /home/jspitz/lyx/lyx-devel/lib/doc/
   ./lib/examples/PDF-form.lyx:\origin D:/LyXGit/Master/lib/examples/
   ./lib/examples/powerdot-example.lyx:\origin 
 D:/LyXGit/Master/lib/examples/
   ./lib/examples/linguistics.lyx:\origin 
 /home/jspitz/lyx/lyx-devel/lib/examples/
   ./lib/examples/de/linguistics.lyx:\origin 
 /home/jspitz/lyx/lyx-devel/lib/examples/de/

This is because those files were modified before 260a98d2. It suffices
editing them with a text editor and performing the change. I am going
to do that.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 10:09:42AM +0200, Stephan Witt wrote:

 Am 18.05.2015 um 09:17 schrieb Enrico Forestieri for...@lyx.org:
 
  On Sun, May 17, 2015 at 11:54:41PM -0700, Pavel Sanda wrote:
  Scott Kostyshak wrote:
  When I am working on the documentation, any save now adds the following:
  
  +\origin /home/scott/lyxbuilds/master/repo/lib/templates/
  
  Do we really have to ship author/login used in the machine?
  I thought we have big fight already that we do not want to put
  such kind of things without explicit permission on the user side.
  
  There will not be any author/login used in the machine. When installing,
  that line will become
  \origin /usr/share/lyx/templates/
 
 How? Perhaps this is true for Linux. For Windows I don't know.
 The installation on a Mac doesn't copy LyX files to system directories.
 It puts all stuff into one application directory. This is either local
 inside my home directory or perhaps some temporary directory.

Stephan, please can you check whether the attached patch works on Mac?
For testing it, as an example, first save lib/examples/thesis/thesis.lyx
in the current format (this is important) and then install LyX as you
usually do with autotools. After that, move your application directory
around and manually copy thesis.lyx somewhere else. I think you should do
something like:
$ cp /path/to/LyXappdir/examples/thesis/thesis.lyx /your/homedir/thesis.lyx

Then try loading the copied file:
$ /path/to/LyXappdir/bin/lyx /your/homedir/thesis.lyx

If it works, all included files should be found. A quick way to check
that is trying to typeset the document. It works if you don't get errors.

-- 
Enrico
diff --git a/lib/Makefile.am b/lib/Makefile.am
index e5d4557..c79596f 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -2308,11 +2308,52 @@ CLEANFILES += lyx@program_suffix@.desktop 
lyx.desktop-temp \
 endif
 dist_noinst_DATA += lyx.desktop.in images/lyx.svg images/lyx.png
 
+exampleandtemplate_files = \
+  $(dist_caexamples_DATA) \
+  $(dist_csexamples_DATA) \
+  $(dist_daexamples_DATA) \
+  $(dist_deexamples_DATA) \
+  $(dist_elexamples_DATA) \
+  $(dist_esexamples_DATA) \
+  $(dist_euexamples_DATA) \
+  $(dist_faexamples_DATA) \
+  $(dist_frexamples_DATA) \
+  $(dist_glexamples_DATA) \
+  $(dist_heexamples_DATA) \
+  $(dist_huexamples_DATA) \
+  $(dist_idexamples_DATA) \
+  $(dist_itexamples_DATA) \
+  $(dist_jaexamples_DATA) \
+  $(dist_koexamples_DATA) \
+  $(dist_nlexamples_DATA) \
+  $(dist_plexamples_DATA) \
+  $(dist_ptexamples_DATA) \
+  $(dist_roexamples_DATA) \
+  $(dist_ruexamples_DATA) \
+  $(dist_slexamples_DATA) \
+  $(dist_skexamples_DATA) \
+  $(dist_srexamples_DATA) \
+  $(dist_svexamples_DATA) \
+  $(dist_springerexamples_DATA) \
+  $(dist_thesisexamples_DATA) \
+  $(dist_ukexamples_DATA) \
+  $(dist_examples_DATA) \
+  $(dist_templates_DATA)
+
 install-data-hook:
$(CHMOD) 755 $(DESTDIR)$(pkgdatadir)/configure.py
for i in $(DESTDIR)$(scriptsdir)/*.py 
$(DESTDIR)$(scriptsdir)/listerrors ; do \
$(CHMOD) 755 $$i; \
done
+   for i in $(exampleandtemplate_files); do \
+   if $(EGREP) -q ^origin  $(DESTDIR)$(pkgdatadir)/$$i; 
then \
+   origin=`dirname /systemlyxdir/$$i`/; \
+   sed -e s|^origin .*|origin $$origin| \
+   $(DESTDIR)$(pkgdatadir)/$$i  
$(DESTDIR)$(pkgdatadir)/$$i.tmp; \
+   mv -f $(DESTDIR)$(pkgdatadir)/$$i.tmp 
$(DESTDIR)$(pkgdatadir)/$$i; \
+   chmod 644 $(DESTDIR)$(pkgdatadir)/$$i; \
+   fi; \
+   done
 
 alltests: check alltests-recursive
 
diff --git a/lib/doc/Makefile.am b/lib/doc/Makefile.am
index 38c545b..e9b9f64 100644
--- a/lib/doc/Makefile.am
+++ b/lib/doc/Makefile.am
@@ -322,8 +322,8 @@ doc_files = \
 install-data-hook:
for i in $(doc_files); \
do \
-   if $(EGREP) -q LYX_DIR_VER|LYX_USERDIR_VER|^\\origin  
$(DESTDIR)$(docdir)/$$i; then \
-   origin=`dirname $(docdir)/$$i`/; \
+   if $(EGREP) -q LYX_DIR_VER|LYX_USERDIR_VER|^origin  
$(DESTDIR)$(docdir)/$$i; then \
+   origin=`dirname /systemlyxdir/doc/$$i`/; \
sed -e s

Re: [LyX/master] Set the origin tag to the proper directory at install time.

[Enrico Forestieri]

On Sun, May 24, 2015 at 11:21:50AM +0200, Kornel Benko wrote:

> Am Sonntag, 24. Mai 2015 um 01:24:42, schrieb Enrico Forestieri 
> <for...@lyx.org>
> > commit 7c48bb0208fac84155a83d2f24041dd0c9198776
> > Author: Enrico Forestieri <for...@lyx.org>
> > Date:   Sun May 24 01:13:41 2015 +0200
> > 
> > Set the origin tag to the proper directory at install time.
> > 
> 
> I prefer that the origin flag in lyx-files in the repository
> be set to unavailable.

By default, it will be after 260a98d2.

> ATM there are some unwanted entries.
>   # find . -name \*.lyx | xargs egrep '\\origin' | egrep -v 
> '(roundtrip|unavailable)'
>   ./lib/doc/Customization.lyx:\origin /home/jspitz/lyx/lyx-devel/lib/doc/
>   ./lib/examples/PDF-form.lyx:\origin D:/LyXGit/Master/lib/examples/
>   ./lib/examples/powerdot-example.lyx:\origin 
> D:/LyXGit/Master/lib/examples/
>   ./lib/examples/linguistics.lyx:\origin 
> /home/jspitz/lyx/lyx-devel/lib/examples/
>   ./lib/examples/de/linguistics.lyx:\origin 
> /home/jspitz/lyx/lyx-devel/lib/examples/de/

This is because those files were modified before 260a98d2. It suffices
editing them with a text editor and performing the change. I am going
to do that.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 10:09:42AM +0200, Stephan Witt wrote:

> Am 18.05.2015 um 09:17 schrieb Enrico Forestieri <for...@lyx.org>:
> 
> > On Sun, May 17, 2015 at 11:54:41PM -0700, Pavel Sanda wrote:
> >> Scott Kostyshak wrote:
> >>> When I am working on the documentation, any save now adds the following:
> >>> 
> >>> +\origin /home/scott/lyxbuilds/master/repo/lib/templates/
> >> 
> >> Do we really have to ship author/login used in the machine?
> >> I thought we have big fight already that we do not want to put
> >> such kind of things without explicit permission on the user side.
> > 
> > There will not be any author/login used in the machine. When installing,
> > that line will become
> > \origin /usr/share/lyx/templates/
> 
> How? Perhaps this is true for Linux. For Windows I don't know.
> The installation on a Mac doesn't copy LyX files to system directories.
> It puts all stuff into one application directory. This is either local
> inside my home directory or perhaps some temporary directory.

Stephan, please can you check whether the attached patch works on Mac?
For testing it, as an example, first save lib/examples/thesis/thesis.lyx
in the current format (this is important) and then install LyX as you
usually do with autotools. After that, move your application directory
around and manually copy thesis.lyx somewhere else. I think you should do
something like:
$ cp /path/to/LyXappdir/examples/thesis/thesis.lyx /your/homedir/thesis.lyx

Then try loading the copied file:
$ /path/to/LyXappdir/bin/lyx /your/homedir/thesis.lyx

If it works, all included files should be found. A quick way to check
that is trying to typeset the document. It works if you don't get errors.

-- 
Enrico
diff --git a/lib/Makefile.am b/lib/Makefile.am
index e5d4557..c79596f 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -2308,11 +2308,52 @@ CLEANFILES += lyx@program_suffix@.desktop 
lyx.desktop-temp \
 endif
 dist_noinst_DATA += lyx.desktop.in images/lyx.svg images/lyx.png
 
+exampleandtemplate_files = \
+  $(dist_caexamples_DATA) \
+  $(dist_csexamples_DATA) \
+  $(dist_daexamples_DATA) \
+  $(dist_deexamples_DATA) \
+  $(dist_elexamples_DATA) \
+  $(dist_esexamples_DATA) \
+  $(dist_euexamples_DATA) \
+  $(dist_faexamples_DATA) \
+  $(dist_frexamples_DATA) \
+  $(dist_glexamples_DATA) \
+  $(dist_heexamples_DATA) \
+  $(dist_huexamples_DATA) \
+  $(dist_idexamples_DATA) \
+  $(dist_itexamples_DATA) \
+  $(dist_jaexamples_DATA) \
+  $(dist_koexamples_DATA) \
+  $(dist_nlexamples_DATA) \
+  $(dist_plexamples_DATA) \
+  $(dist_ptexamples_DATA) \
+  $(dist_roexamples_DATA) \
+  $(dist_ruexamples_DATA) \
+  $(dist_slexamples_DATA) \
+  $(dist_skexamples_DATA) \
+  $(dist_srexamples_DATA) \
+  $(dist_svexamples_DATA) \
+  $(dist_springerexamples_DATA) \
+  $(dist_thesisexamples_DATA) \
+  $(dist_ukexamples_DATA) \
+  $(dist_examples_DATA) \
+  $(dist_templates_DATA)
+
 install-data-hook:
$(CHMOD) 755 $(DESTDIR)$(pkgdatadir)/configure.py
for i in $(DESTDIR)$(scriptsdir)/*.py 
$(DESTDIR)$(scriptsdir)/listerrors ; do \
$(CHMOD) 755 $$i; \
done
+   for i in $(exampleandtemplate_files); do \
+   if $(EGREP) -q "^origin " "$(DESTDIR)$(pkgdatadir)/$$i"; 
then \
+   origin=`dirname "/systemlyxdir/$$i"`/; \
+   sed -e "s|^origin .*|origin $$origin|" \
+   "$(DESTDIR)$(pkgdatadir)/$$i" > 
"$(DESTDIR)$(pkgdatadir)/$$i.tmp"; \
+   mv -f "$(DESTDIR)$(pkgdatadir)/$$i.tmp" 
"$(DESTDIR)$(pkgdatadir)/$$i"; \
+   chmod 644 "$(DESTDIR)$(pkgdatadir)/$$i"; \
+   fi; \
+   done
 
 alltests: check alltests-recursive
 
diff --git a/lib/doc/Makefile.am b/lib/doc/Makefile.am
index 38c545b..e9b9f64 100644
--- a/lib/doc/Makefile.am
+++ b/lib/doc/Makefile.am
@@ -322,8 +322,8 @@ doc_files = \
 install-data-hook:
for i in $(doc_files); \
do \
-   if $(EGREP) -q "LYX_DIR_VER|LYX_USERDIR_VER|^\\origin &

Re: Editclear icon bug

[Enrico Forestieri]

On Thu, May 21, 2015 at 10:52:19PM +0200, Enrico Forestieri wrote:
 On Thu, May 21, 2015 at 09:10:03PM +0200, Jürgen Spitzmüller wrote:
  With qt5/svg icons, go to preferences and type something in the search bar
  of the dialog. A huge editclear icon appears. Apparently the pixmap size
  of the svg icon is wrong.
  
  The attached patch solves it, but I am unsure if it is the best fix.
  
  Stephan, Enrico?
 
 We don't need touching the sources but simply modify the svg image.
 When not specifying anything, the size at which the image is intended
 be displayed by default is used. And currently that is 48x48.
 It is a matter of a minute correcting that. I am going to do it.

Should be fixed now.

-- 
Enrico

Re: Editclear icon bug

[Enrico Forestieri]

On Thu, May 21, 2015 at 09:10:03PM +0200, Jürgen Spitzmüller wrote:
 With qt5/svg icons, go to preferences and type something in the search bar
 of the dialog. A huge editclear icon appears. Apparently the pixmap size
 of the svg icon is wrong.
 
 The attached patch solves it, but I am unsure if it is the best fix.
 
 Stephan, Enrico?

We don't need touching the sources but simply modify the svg image.
When not specifying anything, the size at which the image is intended
be displayed by default is used. And currently that is 48x48.
It is a matter of a minute correcting that. I am going to do it.

-- 
Enrico

Re: Editclear icon bug

[Enrico Forestieri]

On Thu, May 21, 2015 at 09:10:03PM +0200, Jürgen Spitzmüller wrote:
> With qt5/svg icons, go to preferences and type something in the search bar
> of the dialog. A huge "editclear" icon appears. Apparently the pixmap size
> of the svg icon is wrong.
> 
> The attached patch solves it, but I am unsure if it is the best fix.
> 
> Stephan, Enrico?

We don't need touching the sources but simply modify the svg image.
When not specifying anything, the size at which the image is intended
be displayed by default is used. And currently that is 48x48.
It is a matter of a minute correcting that. I am going to do it.

-- 
Enrico

Re: Editclear icon bug

[Enrico Forestieri]

On Thu, May 21, 2015 at 10:52:19PM +0200, Enrico Forestieri wrote:
> On Thu, May 21, 2015 at 09:10:03PM +0200, Jürgen Spitzmüller wrote:
> > With qt5/svg icons, go to preferences and type something in the search bar
> > of the dialog. A huge "editclear" icon appears. Apparently the pixmap size
> > of the svg icon is wrong.
> > 
> > The attached patch solves it, but I am unsure if it is the best fix.
> > 
> > Stephan, Enrico?
> 
> We don't need touching the sources but simply modify the svg image.
> When not specifying anything, the size at which the image is intended
> be displayed by default is used. And currently that is 48x48.
> It is a matter of a minute correcting that. I am going to do it.

Should be fixed now.

-- 
Enrico

Re: new warnings

[Enrico Forestieri]

On Wed, May 20, 2015 at 08:10:25AM +0200, Stephan Witt wrote:
 
 2. InsetCommand.h overloaded virtual function
 In file included from 
 /Users/stephan/git/lyx/src/frontends/qt4/GuiBibitem.cpp:17:
 /Users/stephan/git/lyx/src/insets/InsetCommand.h:69:7: warning: 
 'lyx::InsetCommand::read' hides overloaded virtual function 
 [-Woverloaded-virtual]
 void read(Lexer  lex, Buffer const * buf) { p_.read(lex, buf); }
 /Users/stephan/git/lyx/src/insets/Inset.h:460:15: note: hidden overloaded 
 virtual function 'lyx::Inset::read' declared here
 virtual void read(Lexer ) {}

This one was already reported and I will fix it when I find enough time
to rethink the whole thing. The easiest and fastest way for me is reverting,
but I will try to think of something. This may require some time on my
part. In the mean time, if the warning gives you a restless sleep, you may
add -Wno-overloaded-virtual to CPPFLAGS and be done with it. It will tell
the compiler: Yes, dear compiler, I am overloading that that virtual,
I know it, and it is Ok, please shut up.
Sorry if this may seem harsh, but I am currently fed up with this matter.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Wed, May 20, 2015 at 10:07:02AM +0200, Jean-Marc Lasgouttes wrote:
 Le 19/05/2015 21:42, Enrico Forestieri a écrit :
 I will rarely use this feature, if ever at all. I was simply asked to
 solve a bug. I proposed a patch; there was a discussion lasting for
 a week on the bug tracker; all interested parties were in cc. Nobody
 objected, someone appreciated. I committed. All of a sudden, it was
 a bad idea. Ok, there is always something to learn but I learn fast.
 
 I tried gentle nudges instead of starting a fight because the person who
 does the work gets to decide up to some point (this point is the privacy
 issue here). This does not mean that I did not object.

Ok, let's stop this fruitless discussion here, please.

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Wed, May 20, 2015 at 12:25:16PM +0200, Jean-Marc Lasgouttes wrote:
 Le 16/05/2015 17:06, Enrico Forestieri a écrit :
 On Sat, May 16, 2015 at 01:50:26PM +0200, Jean-Marc Lasgouttes wrote:
 
 Le 16/05/2015 03:48, Enrico Forestieri a écrit :
 Incidentally, for this same reason I cannot simply run ./autogen.sh
 but have to run bash autogen.sh. This is really minor, though, as
 
 What is the error with autogen.sh? Is it the ! with make?
 
 Yes, exactly.
 
 Is it better now?

Yes, thanks.

-- 
Enrico

Re: [LyX/master] Correctly load documents moved elsewhere after save.

[Enrico Forestieri]

On Mon, May 18, 2015 at 10:42:03AM +0200, Jean-Marc Lasgouttes wrote:
 Le 16/05/2015 19:52, Enrico Forestieri a écrit :
 commit 62d36bf04d436c83ddace8aeaf4dbd493d674cdf
 Author: Enrico Forestieri for...@lyx.org
 Date:   Sat May 16 19:51:53 2015 +0200
 
  Correctly load documents moved elsewhere after save.
 
 Now clang complains because of the new InsetCommand::read() signature (see
 below).
 
 Solutions include changing the name of the new method or declaring such a
 mathod at Inset level if it makes sense.

Should be fixed now.

 Some documentation of the Buffer
 const * parameter would be useful too. Is it supposed to be the buffer of
 the Inset or something else?

It is only needed for accessing the includedFilePath() method, so any will do.

 ../../master/src/insets/InsetCommand.h:69:7: warning:
 'lyx::InsetCommand::read'
   hides overloaded virtual function [-Woverloaded-virtual]
 void read(Lexer  lex, Buffer const * buf) { p_.read(lex, buf); }
  ^
 ../../master/src/insets/Inset.h:460:15: note: hidden overloaded virtual
 function
   'lyx::Inset::read' declared here: different number of parameters (1 vs
 2)
 virtual void read(Lexer ) {}
  ^
 1 warning generated.
 
 

-- 
Enrico

Re: [LyX/master] Correctly load documents moved elsewhere after save.

[Enrico Forestieri]

On Wed, May 20, 2015 at 04:20:19PM +0200, Jean-Marc Lasgouttes wrote:
 Le 20/05/2015 15:53, Enrico Forestieri a écrit :
 Solutions include changing the name of the new method or declaring such a
 mathod at Inset level if it makes sense.
 
 Should be fixed now.
 
 Some documentation of the Buffer
 const * parameter would be useful too. Is it supposed to be the buffer of
 the Inset or something else?
 
 It is only needed for accessing the includedFilePath() method, so any will 
 do.
 
 So why can't one use Inset::buffer() directly?

Unless I am missing something, it is not available in InsetCommandParams.

-- 
Enrico

Re: new warnings

[Enrico Forestieri]

On Wed, May 20, 2015 at 08:10:25AM +0200, Stephan Witt wrote:
> 
> 2. InsetCommand.h overloaded virtual function
> In file included from 
> /Users/stephan/git/lyx/src/frontends/qt4/GuiBibitem.cpp:17:
> /Users/stephan/git/lyx/src/insets/InsetCommand.h:69:7: warning: 
> 'lyx::InsetCommand::read' hides overloaded virtual function 
> [-Woverloaded-virtual]
> void read(Lexer & lex, Buffer const * buf) { p_.read(lex, buf); }
> /Users/stephan/git/lyx/src/insets/Inset.h:460:15: note: hidden overloaded 
> virtual function 'lyx::Inset::read' declared here
> virtual void read(Lexer &) {}

This one was already reported and I will fix it when I find enough time
to rethink the whole thing. The easiest and fastest way for me is reverting,
but I will try to think of something. This may require some time on my
part. In the mean time, if the warning gives you a restless sleep, you may
add -Wno-overloaded-virtual to CPPFLAGS and be done with it. It will tell
the compiler: "Yes, dear compiler, I am overloading that that virtual,
I know it, and it is Ok, please shut up".
Sorry if this may seem harsh, but I am currently fed up with this matter.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Wed, May 20, 2015 at 10:07:02AM +0200, Jean-Marc Lasgouttes wrote:
> Le 19/05/2015 21:42, Enrico Forestieri a écrit :
> >I will rarely use this feature, if ever at all. I was simply asked to
> >solve a bug. I proposed a patch; there was a discussion lasting for
> >a week on the bug tracker; all interested parties were in cc. Nobody
> >objected, someone appreciated. I committed. All of a sudden, it was
> >a bad idea. Ok, there is always something to learn but I learn fast.
> 
> I tried gentle nudges instead of starting a fight because the person who
> does the work gets to decide up to some point (this point is the privacy
> issue here). This does not mean that I did not object.

Ok, let's stop this fruitless discussion here, please.

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Wed, May 20, 2015 at 12:25:16PM +0200, Jean-Marc Lasgouttes wrote:
> Le 16/05/2015 17:06, Enrico Forestieri a écrit :
> >On Sat, May 16, 2015 at 01:50:26PM +0200, Jean-Marc Lasgouttes wrote:
> >
> >>Le 16/05/2015 03:48, Enrico Forestieri a écrit :
> >>>Incidentally, for this same reason I cannot simply run ./autogen.sh
> >>>but have to run "bash autogen.sh". This is really minor, though, as
> >>
> >>What is the error with autogen.sh? Is it the "!" with make?
> >
> >Yes, exactly.
> 
> Is it better now?

Yes, thanks.

-- 
Enrico

Re: [LyX/master] Correctly load documents moved elsewhere after save.

[Enrico Forestieri]

On Mon, May 18, 2015 at 10:42:03AM +0200, Jean-Marc Lasgouttes wrote:
> Le 16/05/2015 19:52, Enrico Forestieri a écrit :
> >commit 62d36bf04d436c83ddace8aeaf4dbd493d674cdf
> >Author: Enrico Forestieri <for...@lyx.org>
> >Date:   Sat May 16 19:51:53 2015 +0200
> >
> > Correctly load documents moved elsewhere after save.
> 
> Now clang complains because of the new InsetCommand::read() signature (see
> below).
> 
> Solutions include changing the name of the new method or declaring such a
> mathod at Inset level if it makes sense.

Should be fixed now.

> Some documentation of the Buffer
> const * parameter would be useful too. Is it supposed to be the buffer of
> the Inset or something else?

It is only needed for accessing the includedFilePath() method, so any will do.

> ../../master/src/insets/InsetCommand.h:69:7: warning:
> 'lyx::InsetCommand::read'
>   hides overloaded virtual function [-Woverloaded-virtual]
> void read(Lexer & lex, Buffer const * buf) { p_.read(lex, buf); }
>  ^
> ../../master/src/insets/Inset.h:460:15: note: hidden overloaded virtual
> function
>   'lyx::Inset::read' declared here: different number of parameters (1 vs
> 2)
> virtual void read(Lexer &) {}
>  ^
> 1 warning generated.
> 
> 

-- 
Enrico

Re: [LyX/master] Correctly load documents moved elsewhere after save.

[Enrico Forestieri]

On Wed, May 20, 2015 at 04:20:19PM +0200, Jean-Marc Lasgouttes wrote:
> Le 20/05/2015 15:53, Enrico Forestieri a écrit :
> >>Solutions include changing the name of the new method or declaring such a
> >>mathod at Inset level if it makes sense.
> >
> >Should be fixed now.
> >
> >>Some documentation of the Buffer
> >>const * parameter would be useful too. Is it supposed to be the buffer of
> >>the Inset or something else?
> >
> >It is only needed for accessing the includedFilePath() method, so any will 
> >do.
> 
> So why can't one use Inset::buffer() directly?

Unless I am missing something, it is not available in InsetCommandParams.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 05:28:41PM -0700, Pavel Sanda wrote:
 Enrico Forestieri wrote:
  It's magic and it's very predictable. An alternative to reverting
  would be introducing a preference to allow storing the \origin tag
  in the file. Without that tag, everything would go as before.
 
 I'm fine with any of the alternatives above.

Another alternative is that of obfuscating the tag.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Tue, May 19, 2015 at 11:09:26AM +0200, Jean-Marc Lasgouttes wrote:
 Le 18/05/2015 20:15, Enrico Forestieri a écrit :
 Something with less magic and more predictability?
 
 It's magic and it's very predictable. An alternative to reverting
 would be introducing a preference to allow storing the \origin tag
 in the file. Without that tag, everything would go as before.
 
 I'd say that a pref would be helpful, then.

I would rather avoid introducing a new pref. If the concern is really
the disclosure of a local path, it could also be avoided by encrypting
the path using a key. Then, only lyx (and who is able to know the key
and the used algorithm, of course) would be able to make sense of a
seemingly random string.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Tue, May 19, 2015 at 08:42:45PM +0200, Georg Baum wrote:
 Enrico Forestieri wrote:
 
  On Tue, May 19, 2015 at 11:09:26AM +0200, Jean-Marc Lasgouttes wrote:
  Le 18/05/2015 20:15, Enrico Forestieri a écrit :
  Something with less magic and more predictability?
  
  It's magic and it's very predictable. An alternative to reverting
  would be introducing a preference to allow storing the \origin tag
  in the file. Without that tag, everything would go as before.
  
  I'd say that a pref would be helpful, then.
  
  I would rather avoid introducing a new pref. If the concern is really
  the disclosure of a local path, it could also be avoided by encrypting
  the path using a key. Then, only lyx (and who is able to know the key
  and the used algorithm, of course) would be able to make sense of a
  seemingly random string.
 
 Sorry for chiming in so late, I missed the original discussion.
 
 I do not like it at all if software puts information about my machine in 
 files that are used for data exchange without my consent. If the information 
 is there, but obfuscated this is even worse, because then I cannot see what 
 information is leaked. This is IMHO not far away from telephoning home and 
 sending some undocumented binary data.
 
 I understand the use case for the origin parameter, and I think there will 
 be users who appreciate it, but if I don't need it (e.g. because I always 
 store relative file names and do only move the complete document hierarchy), 
 then I do not want at all that absolute paths are stored somewhere.

But lyx stores them in documents when using browseRelToParent() and
browseRelToSub(). The fact that the user can change them is no escuse
because it is not intuitive, as #7540 demonstrates.
So, should we also ditch those two methods?

 I think the LyX documentation is a good test case: It uses exclusively 
 relative paths, so no origin is needed.

I will rarely use this feature, if ever at all. I was simply asked to
solve a bug. I proposed a patch; there was a discussion lasting for
a week on the bug tracker; all interested parties were in cc. Nobody
objected, someone appreciated. I committed. All of a sudden, it was
a bad idea. Ok, there is always something to learn but I learn fast.

-- 
Enrico

Re: New requirement: X11/Intrisic.h

[Enrico Forestieri]

On Tue, May 19, 2015 at 03:33:46PM +0200, Jean-Marc Lasgouttes wrote:
 Le 19/05/2015 08:08, Vincent van Ravesteijn a écrit :
 Since commit ([52fee355/lyxgit]; Fix external middle-mouse pasting
 with Qt5/X11), I need X11/Intrinsic.h for which I had to install the
 package libxt-devel.
 
 Does this need a check in configure.ac ?, and/or a note in the RELEASE_NOTES 
 ?
 
 Enrico, could you check that? It is very strange that we could need
 something from libXt for a supposedly libxcb backend.

We don't need anything from libXt but only the definition of XA_PRIMARY
and I did not find any other way for getting that. It did not occur
to me that they could have changed name to something so basilar, but
they did, apparently. The documentation for xcb is ..., well, is ...
let's say full of gaps. I had to grep the includes to discover what
I should have used. They are the same value, of course, but XA_PRIMARY
is a define, while XCB_ATOM_PRIMARY is an enum value. Should be fixed now.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 05:28:41PM -0700, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > It's magic and it's very predictable. An alternative to reverting
> > would be introducing a preference to allow storing the \origin tag
> > in the file. Without that tag, everything would go as before.
> 
> I'm fine with any of the alternatives above.

Another alternative is that of obfuscating the tag.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Tue, May 19, 2015 at 11:09:26AM +0200, Jean-Marc Lasgouttes wrote:
> Le 18/05/2015 20:15, Enrico Forestieri a écrit :
> >>Something with less magic and more predictability?
> >
> >It's magic and it's very predictable. An alternative to reverting
> >would be introducing a preference to allow storing the \origin tag
> >in the file. Without that tag, everything would go as before.
> 
> I'd say that a pref would be helpful, then.

I would rather avoid introducing a new pref. If the concern is really
the disclosure of a local path, it could also be avoided by encrypting
the path using a key. Then, only lyx (and who is able to know the key
and the used algorithm, of course) would be able to make sense of a
seemingly random string.

-- 
Enrico

Re: New requirement: X11/Intrisic.h

[Enrico Forestieri]

On Tue, May 19, 2015 at 03:33:46PM +0200, Jean-Marc Lasgouttes wrote:
> Le 19/05/2015 08:08, Vincent van Ravesteijn a écrit :
> >Since commit ([52fee355/lyxgit]; "Fix external middle-mouse pasting
> >with Qt5/X11"), I need X11/Intrinsic.h for which I had to install the
> >package libxt-devel.
> >
> >Does this need a check in configure.ac ?, and/or a note in the RELEASE_NOTES 
> >?
> 
> Enrico, could you check that? It is very strange that we could need
> something from libXt for a supposedly libxcb backend.

We don't need anything from libXt but only the definition of XA_PRIMARY
and I did not find any other way for getting that. It did not occur
to me that they could have changed name to something so basilar, but
they did, apparently. The documentation for xcb is ..., well, is ...
let's say full of gaps. I had to grep the includes to discover what
I should have used. They are the same value, of course, but XA_PRIMARY
is a define, while XCB_ATOM_PRIMARY is an enum value. Should be fixed now.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Tue, May 19, 2015 at 08:42:45PM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
> 
> > On Tue, May 19, 2015 at 11:09:26AM +0200, Jean-Marc Lasgouttes wrote:
> >> Le 18/05/2015 20:15, Enrico Forestieri a écrit :
> >> >>Something with less magic and more predictability?
> >> >
> >> >It's magic and it's very predictable. An alternative to reverting
> >> >would be introducing a preference to allow storing the \origin tag
> >> >in the file. Without that tag, everything would go as before.
> >> 
> >> I'd say that a pref would be helpful, then.
> > 
> > I would rather avoid introducing a new pref. If the concern is really
> > the disclosure of a local path, it could also be avoided by encrypting
> > the path using a key. Then, only lyx (and who is able to know the key
> > and the used algorithm, of course) would be able to make sense of a
> > seemingly random string.
> 
> Sorry for chiming in so late, I missed the original discussion.
> 
> I do not like it at all if software puts information about my machine in 
> files that are used for data exchange without my consent. If the information 
> is there, but obfuscated this is even worse, because then I cannot see what 
> information is leaked. This is IMHO not far away from telephoning home and 
> sending some undocumented binary data.
> 
> I understand the use case for the origin parameter, and I think there will 
> be users who appreciate it, but if I don't need it (e.g. because I always 
> store relative file names and do only move the complete document hierarchy), 
> then I do not want at all that absolute paths are stored somewhere.

But lyx stores them in documents when using browseRelToParent() and
browseRelToSub(). The fact that the user can change them is no escuse
because it is not intuitive, as #7540 demonstrates.
So, should we also ditch those two methods?

> I think the LyX documentation is a good test case: It uses exclusively 
> relative paths, so no origin is needed.

I will rarely use this feature, if ever at all. I was simply asked to
solve a bug. I proposed a patch; there was a discussion lasting for
a week on the bug tracker; all interested parties were in cc. Nobody
objected, someone appreciated. I committed. All of a sudden, it was
a bad idea. Ok, there is always something to learn but I learn fast.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 11:14:19AM +0200, Jean-Marc Lasgouttes wrote:
 Le 18/05/2015 11:07, Enrico Forestieri a écrit :
 
 Anyway, I am ready to revert everything if this is wanted.
 
 I do not know whether reverting everything is what is needed. I do not feel
 very at ease with a solution where doing save as is not the same as moving
 the file from command line, it feels a bit fragile to me.

Actually, it turns out to be very robust. Wherever you move your document
the needed files will be found, unless you move them, too. And if you do,
things would go as before.

 OTOH, from what I understand, the origin acts as a backup when some relative
 paths do not point to an existing file anymore, right? Could we find a user
 friendly way to ask the user for this path when it turns out that we cannot
 find some files anymore?

This is clumsy and is not going to work if you don't remember from where
you moved your document, maybe because you reopen it a month later.

 Something with less magic and more predictability?

It's magic and it's very predictable. An alternative to reverting
would be introducing a preference to allow storing the \origin tag
in the file. Without that tag, everything would go as before.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Sun, May 17, 2015 at 11:54:41PM -0700, Pavel Sanda wrote:
 Scott Kostyshak wrote:
  When I am working on the documentation, any save now adds the following:
  
  +\origin /home/scott/lyxbuilds/master/repo/lib/templates/
 
 Do we really have to ship author/login used in the machine?
 I thought we have big fight already that we do not want to put
 such kind of things without explicit permission on the user side.

There will not be any author/login used in the machine. When installing,
that line will become
\origin /usr/share/lyx/templates/

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Sun, May 17, 2015 at 09:11:32PM -0400, Scott Kostyshak wrote:
 When I am working on the documentation, any save now adds the following:
 
 +\origin /home/scott/lyxbuilds/master/repo/lib/templates/
 
 I just want to confirm that when I commit, it is correct that this
 will be added to the LyX documentation files that we will ship. It is
 indeed expected, right?

Yes. At install time that path will be replaced with the correct one
through an install-data-hook target (to be done), as already done for
updating LYX_DIR_VER and LYX_USERDIR_VER in the documentation files.
See http://www.lyx.org/trac/changeset/26119/lyxsvn

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 10:09:42AM +0200, Stephan Witt wrote:
 Am 18.05.2015 um 09:17 schrieb Enrico Forestieri for...@lyx.org:
 
  On Sun, May 17, 2015 at 11:54:41PM -0700, Pavel Sanda wrote:
  Scott Kostyshak wrote:
  When I am working on the documentation, any save now adds the following:
  
  +\origin /home/scott/lyxbuilds/master/repo/lib/templates/
  
  Do we really have to ship author/login used in the machine?
  I thought we have big fight already that we do not want to put
  such kind of things without explicit permission on the user side.
  
  There will not be any author/login used in the machine. When installing,
  that line will become
  \origin /usr/share/lyx/templates/
 
 How? Perhaps this is true for Linux. For Windows I don't know.
 The installation on a Mac doesn't copy LyX files to system directories.
 It puts all stuff into one application directory. This is either local
 inside my home directory or perhaps some temporary directory.

Sorry, I am not familiar about how things work on Mac. If you have
an installer, you could replace those lines when they get installed
but, again, I know nothing about Macs.

Anyway, I am ready to revert everything if this is wanted.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 11:09:25AM +0200, Jean-Marc Lasgouttes wrote:
 Le 18/05/2015 11:02, Enrico Forestieri a écrit :
 Yes, but user files will contain this information... Isn't there a way to
 avoid it at least when it is not useful?
 
 The user files already contain this information when storing absolute
 paths. If I recall correctly, you strongly wanted absolute paths in
 documents, don't you?
 
 Read again. In the old scheme, absolute paths were proposed by the file
 browser in some specific cases; the users could see them and had an
 opportunity to remove them. Now we have an absolute path in the .lyx file
 without opt-out possibility. It feels wrong.

Well, I'll revert then. Don't have much time now. Will do when I get some.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 09:50:00AM +0200, Jean-Marc Lasgouttes wrote:
 Le 18/05/2015 09:17, Enrico Forestieri a écrit :
 Do we really have to ship author/login used in the machine?
 I thought we have big fight already that we do not want to put
 such kind of things without explicit permission on the user side.
 
 There will not be any author/login used in the machine. When installing,
 that line will become
 \origin /usr/share/lyx/templates/
 
 Yes, but user files will contain this information... Isn't there a way to
 avoid it at least when it is not useful?

The user files already contain this information when storing absolute
paths. If I recall correctly, you strongly wanted absolute paths in
documents, don't you?

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Sun, May 17, 2015 at 09:11:32PM -0400, Scott Kostyshak wrote:
> When I am working on the documentation, any save now adds the following:
> 
> +\origin /home/scott/lyxbuilds/master/repo/lib/templates/
> 
> I just want to confirm that when I commit, it is correct that this
> will be added to the LyX documentation files that we will ship. It is
> indeed expected, right?

Yes. At install time that path will be replaced with the correct one
through an install-data-hook target (to be done), as already done for
updating LYX_DIR_VER and LYX_USERDIR_VER in the documentation files.
See http://www.lyx.org/trac/changeset/26119/lyxsvn

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Sun, May 17, 2015 at 11:54:41PM -0700, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > When I am working on the documentation, any save now adds the following:
> > 
> > +\origin /home/scott/lyxbuilds/master/repo/lib/templates/
> 
> Do we really have to ship author/login used in the machine?
> I thought we have big fight already that we do not want to put
> such kind of things without explicit permission on the user side.

There will not be any author/login used in the machine. When installing,
that line will become
\origin /usr/share/lyx/templates/

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 09:50:00AM +0200, Jean-Marc Lasgouttes wrote:
> Le 18/05/2015 09:17, Enrico Forestieri a écrit :
> >>Do we really have to ship author/login used in the machine?
> >>I thought we have big fight already that we do not want to put
> >>such kind of things without explicit permission on the user side.
> >
> >There will not be any author/login used in the machine. When installing,
> >that line will become
> >\origin /usr/share/lyx/templates/
> 
> Yes, but user files will contain this information... Isn't there a way to
> avoid it at least when it is not useful?

The user files already contain this information when storing absolute
paths. If I recall correctly, you strongly wanted absolute paths in
documents, don't you?

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 10:09:42AM +0200, Stephan Witt wrote:
> Am 18.05.2015 um 09:17 schrieb Enrico Forestieri <for...@lyx.org>:
> 
> > On Sun, May 17, 2015 at 11:54:41PM -0700, Pavel Sanda wrote:
> >> Scott Kostyshak wrote:
> >>> When I am working on the documentation, any save now adds the following:
> >>> 
> >>> +\origin /home/scott/lyxbuilds/master/repo/lib/templates/
> >> 
> >> Do we really have to ship author/login used in the machine?
> >> I thought we have big fight already that we do not want to put
> >> such kind of things without explicit permission on the user side.
> > 
> > There will not be any author/login used in the machine. When installing,
> > that line will become
> > \origin /usr/share/lyx/templates/
> 
> How? Perhaps this is true for Linux. For Windows I don't know.
> The installation on a Mac doesn't copy LyX files to system directories.
> It puts all stuff into one application directory. This is either local
> inside my home directory or perhaps some temporary directory.

Sorry, I am not familiar about how things work on Mac. If you have
an installer, you could replace those lines when they get installed
but, again, I know nothing about Macs.

Anyway, I am ready to revert everything if this is wanted.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 11:09:25AM +0200, Jean-Marc Lasgouttes wrote:
> Le 18/05/2015 11:02, Enrico Forestieri a écrit :
> >>Yes, but user files will contain this information... Isn't there a way to
> >>avoid it at least when it is not useful?
> >
> >The user files already contain this information when storing absolute
> >paths. If I recall correctly, you strongly wanted absolute paths in
> >documents, don't you?
> 
> Read again. In the old scheme, absolute paths were proposed by the file
> browser in some specific cases; the users could see them and had an
> opportunity to remove them. Now we have an absolute path in the .lyx file
> without opt-out possibility. It feels wrong.

Well, I'll revert then. Don't have much time now. Will do when I get some.

-- 
Enrico

Re: Understanding the /origin parameter

[Enrico Forestieri]

On Mon, May 18, 2015 at 11:14:19AM +0200, Jean-Marc Lasgouttes wrote:
> Le 18/05/2015 11:07, Enrico Forestieri a écrit :
> 
> >Anyway, I am ready to revert everything if this is wanted.
> 
> I do not know whether reverting everything is what is needed. I do not feel
> very at ease with a solution where doing save as is not the same as moving
> the file from command line, it feels a bit fragile to me.

Actually, it turns out to be very robust. Wherever you move your document
the needed files will be found, unless you move them, too. And if you do,
things would go as before.

> OTOH, from what I understand, the origin acts as a backup when some relative
> paths do not point to an existing file anymore, right? Could we find a user
> friendly way to ask the user for this path when it turns out that we cannot
> find some files anymore?

This is clumsy and is not going to work if you don't remember from where
you moved your document, maybe because you reopen it a month later.

> Something with less magic and more predictability?

It's magic and it's very predictable. An alternative to reverting
would be introducing a preference to allow storing the \origin tag
in the file. Without that tag, everything would go as before.

-- 
Enrico

Re: lyx2lyx script failed

[Enrico Forestieri]

On Sun, May 17, 2015 at 02:50:00PM +0200, Georg Baum wrote:

 hatim ali wrote:
 
  Dear Uwe Stoehr
  
  not work, this the msg:
  
  Traceback (most recent call last):
File /usr/local/share/lyx/lyx2lyx/lyx2lyx, line 86, in module
  main()
File /usr/local/share/lyx/lyx2lyx/lyx2lyx, line 81, in main
  doc.write()
File /usr/local/share/lyx/lyx2lyx/LyX.py, line 369, in write
  self.output.write(line.encode(self.encoding)+\n)
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xd8 in position 44:
  ordinal not in range(128) Error: فشل تحويل المخطوطة
  
 
 This means that lyx2lyx can't write the output in utf8 encoding, since it 
 can't decode the line. Since others cannot reproduce the problem with 
 directories consisting only of ASCII characters, and it appeared quite 
 recently, my guess would be that convert_origin() adds the document 
 directory using the wrong encoding.

Indeed, convert_origin() uses document.dir, which is encoded according to
the file system encoding. Should be fixed now.

-- 
Enrico

Re: lyx2lyx script failed

[Enrico Forestieri]

On Sun, May 17, 2015 at 02:50:00PM +0200, Georg Baum wrote:

> hatim ali wrote:
> 
> > Dear Uwe Stoehr
> > 
> > not work, this the msg:
> > 
> > Traceback (most recent call last):
> >   File "/usr/local/share/lyx/lyx2lyx/lyx2lyx", line 86, in 
> > main()
> >   File "/usr/local/share/lyx/lyx2lyx/lyx2lyx", line 81, in main
> > doc.write()
> >   File "/usr/local/share/lyx/lyx2lyx/LyX.py", line 369, in write
> > self.output.write(line.encode(self.encoding)+"\n")
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xd8 in position 44:
> > ordinal not in range(128) Error: فشل تحويل المخطوطة
> > 
> 
> This means that lyx2lyx can't write the output in utf8 encoding, since it 
> can't decode the line. Since others cannot reproduce the problem with 
> directories consisting only of ASCII characters, and it appeared quite 
> recently, my guess would be that convert_origin() adds the document 
> directory using the wrong encoding.

Indeed, convert_origin() uses document.dir, which is encoded according to
the file system encoding. Should be fixed now.

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Sat, May 16, 2015 at 01:50:26PM +0200, Jean-Marc Lasgouttes wrote:

 Le 16/05/2015 03:48, Enrico Forestieri a écrit :
 Incidentally, for this same reason I cannot simply run ./autogen.sh
 but have to run bash autogen.sh. This is really minor, though, as
 
 What is the error with autogen.sh? Is it the ! with make?

Yes, exactly.

$ ./autogen.sh 
Using automake (GNU automake) 1.11.1
Using autoconf (GNU Autoconf) 2.68
Building macros...
Building config header template...
Building Makefile templates...
Building configure...
Building po/POTFILES.in...
./autogen.sh: !: not found

run ./configure  make

-- 
Enrico

Re: [LyX/master] Correctly load documents moved elsewhere after save.

[Enrico Forestieri]

On Sat, May 16, 2015 at 07:52:43PM +0200, Enrico Forestieri wrote:
 
 --- a/src/insets/InsetCommandParams.cpp
 +++ b/src/insets/InsetCommandParams.cpp
 @@ -353,6 +371,8 @@ void InsetCommandParams::Write(ostream  os, Buffer const 
 * buffer) const
   bib = token(data, ',', ++i);
   }
   data = newdata;
 + } else if (buffer  name == options) {
 + data = buffer-includedFilePath(data, bst);
   }
   os  name  ' '
   Lexer::quoteString(data)

Richard, the above hunk has to be applied to stable, too. It takes care of
updating the path of the .bst files when saving to a different location.
I was missing this bit in the corresponding commit.

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Sat, May 16, 2015 at 11:12:04AM +0200, Georg Baum wrote:

 Enrico Forestieri wrote:
 
  I have not investigated, but I think this is due to some script assuming
  that /bin/sh is really /bin/bash, and this is not true on solaris.
 
 In fact I did not know that ! is bash specific. It should work now.

Yes, it works now. Thanks.

  Incidentally, for this same reason I cannot simply run ./autogen.sh
  but have to run bash autogen.sh. This is really minor, though, as
 
 In this case I have no idea what causes the problem.

It is exactly the same issue.

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Sat, May 16, 2015 at 11:12:04AM +0200, Georg Baum wrote:

> Enrico Forestieri wrote:
> 
> > I have not investigated, but I think this is due to some script assuming
> > that /bin/sh is really /bin/bash, and this is not true on solaris.
> 
> In fact I did not know that ! is bash specific. It should work now.

Yes, it works now. Thanks.

> > Incidentally, for this same reason I cannot simply run ./autogen.sh
> > but have to run "bash autogen.sh". This is really minor, though, as
> 
> In this case I have no idea what causes the problem.

It is exactly the same issue.

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Sat, May 16, 2015 at 01:50:26PM +0200, Jean-Marc Lasgouttes wrote:

> Le 16/05/2015 03:48, Enrico Forestieri a écrit :
> >Incidentally, for this same reason I cannot simply run ./autogen.sh
> >but have to run "bash autogen.sh". This is really minor, though, as
> 
> What is the error with autogen.sh? Is it the "!" with make?

Yes, exactly.

$ ./autogen.sh 
Using automake (GNU automake) 1.11.1
Using autoconf (GNU Autoconf) 2.68
Building macros...
Building config header template...
Building Makefile templates...
Building configure...
Building po/POTFILES.in...
./autogen.sh: !: not found

run "./configure && make"

-- 
Enrico

Re: [LyX/master] Correctly load documents moved elsewhere after save.

[Enrico Forestieri]

On Sat, May 16, 2015 at 07:52:43PM +0200, Enrico Forestieri wrote:
> 
> --- a/src/insets/InsetCommandParams.cpp
> +++ b/src/insets/InsetCommandParams.cpp
> @@ -353,6 +371,8 @@ void InsetCommandParams::Write(ostream & os, Buffer const 
> * buffer) const
>   bib = token(data, ',', ++i);
>   }
>   data = newdata;
> + } else if (buffer && name == "options") {
> + data = buffer->includedFilePath(data, "bst");
>   }
>   os << name << ' '
>  << Lexer::quoteString(data)

Richard, the above hunk has to be applied to stable, too. It takes care of
updating the path of the .bst files when saving to a different location.
I was missing this bit in the corresponding commit.

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
 
 Thank you. The current splash has a size of 400x250. I'll attach the
 1600x1000 splash banner to test.
 It would be great if this is ok too. If not I have to get it right myself.

Why is this (compressed) svg image so big? Are you sure there is no
embedded bitmap? That would defeat the purpose of using the svg format.

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
 
 I'll try to get it running on Linux to see how it works there. Meanwhile,
 I'm interested in comments.

Please, don't pass back and forth QPixmap objects on the stack. These
are big objects, potentially. Instead, use

bool getPixmap(QString const  path, QPixmap  pm)
{
// deal with QPixmap

return !pm.isNull();
}

 
 diff --git a/src/frontends/qt4/GuiApplication.cpp 
 b/src/frontends/qt4/GuiApplication.cpp
 index eaf33c4..de4569a 100644
 --- a/src/frontends/qt4/GuiApplication.cpp
 +++ b/src/frontends/qt4/GuiApplication.cpp
 @@ -569,22 +569,39 @@ QString iconName(FuncRequest const  f, bool unknown)
   return QString();
  }
  
 -QPixmap getPixmap(QString const  path, QString const  name, QString const 
  ext)
 +QPixmap getPixmap(QString const  path)
  {
   QPixmap pixmap;
 + if (pixmap.load(path)) {
 + if (path.endsWith(.svgz) || path.endsWith(.svg) ) {
 + GuiApplication const * guiApp = theGuiApp();
 + if (guiApp != 0) {
 + 
 pixmap.setDevicePixelRatio(guiApp-pixelRatio());
 + }
 + }
 + return pixmap;
 + }
 + return QPixmap();
 +}
 +
 +QPixmap getPixmap(QString const  path, QString const  name, QString const 
  ext)
 +{
   QString imagedir = path;
   FileName fname = imageLibFileSearch(imagedir, name, ext, 
 theGuiApp()-imageSearchMode());
   QString fpath = toqstr(fname.absFileName());
 + QPixmap pixmap = getPixmap(fpath);
  
 - if (pixmap.load(fpath)) {
 + if (!pixmap.isNull()) {
   return pixmap;
 - } else {
 - QStringList exts = ext.split(,);
 - fpath = :/ + path + name + .;
 - for (int i = 0; i  exts.size(); ++i) {
 - if (pixmap.load(fpath + exts.at(i)))
 + }
 + 
 + QStringList exts = ext.split(,);
 + fpath = :/ + path + name + .;
 + for (int i = 0; i  exts.size(); ++i) {
 + pixmap = getPixmap(fpath + exts.at(i));
 + if (!pixmap.isNull()) {
   return pixmap;
 - }
 + }
   }
  
   bool const list = ext.contains(,);
 @@ -613,13 +630,13 @@ QIcon getIcon(FuncRequest const  f, bool unknown)
   return QIcon();
  
   //LYXERR(Debug::GUI, Found icon:   icon);
 - QPixmap pm;
 - if (!pm.load(icon)) {
 + QPixmap pixmap = getPixmap(icon);
 + if (pixmap.isNull()) {
   LYXERR0(Cannot load icon   icon   please verify resource 
 system!);
   return QIcon();
   }
  
 - return QIcon(pm);
 + return QIcon(pixmap);
  }
  
  

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 03:45:28PM +0200, Stephan Witt wrote:

 Am 15.05.2015 um 15:14 schrieb Enrico Forestieri for...@lyx.org:
 
  On Fri, May 15, 2015 at 02:53:22PM +0200, Enrico Forestieri wrote:
  On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
  
  Thank you. The current splash has a size of 400x250. I'll attach the
  1600x1000 splash banner to test.
  It would be great if this is ok too. If not I have to get it right myself.
  
  Why is this (compressed) svg image so big? Are you sure there is no
  embedded bitmap? That would defeat the purpose of using the svg format.
  
  Indeed, I found the attached 4 (base64 encoded) bitmaps embedded in the svg.
  That's bad.
 
 Yes, Jürgen said it would be great to find someone who is able to do it 
 better.
 This one was made to have some SVG banner.

Sorry, I did not realize it was that same banner. But why did you attach it, 
then?

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 04:58:24PM +0200, Stephan Witt wrote:

 Am 15.05.2015 um 16:48 schrieb Enrico Forestieri for...@lyx.org:
 
  On Fri, May 15, 2015 at 04:31:05PM +0200, Stephan Witt wrote:
  
  This results in the following patch - if you had something like that in
  mind I'll split it in two patches. The other getPixmap method with
  QPixmap result was already there.
  
  Yes, I think that it is better passing big objects by reference rather
  than by value.
 
 But this is not a good property of C++ compilers than.
 1. It's not a constant fact if an object is big.
 2. The compiler should generate fast code for this scenario too.
 3. This results in hard to read code eventually.

You are probably right and it seems people prefer the simpler approach by
relying on the return value optimization performed by modern compilers.
http://stackoverflow.com/questions/753312/returning-large-objects-in-functions
http://stackoverflow.com/questions/4809120/creating-and-returning-a-big-object-from-a-function
http://stackoverflow.com/questions/24685054/how-do-c-functions-return-a-big-object-or-a-structure

What triggered my comment was seeing that call in a loop, so you could simply
limit the change to that one function and leave the rest as is. Or you could
also disregard that comment ;-)

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 04:31:05PM +0200, Stephan Witt wrote:
 
 This results in the following patch - if you had something like that in
 mind I'll split it in two patches. The other getPixmap method with
 QPixmap result was already there.

Yes, I think that it is better passing big objects by reference rather
than by value.

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Fri, May 15, 2015 at 09:06:34PM +0200, Georg Baum wrote:
 
 Can you try again pelase? c_str() was not instantiated explicitly (because 
 on linux it is automatically instantiated).

Yes, it now compiles on both solaris and cygwin. However, on solaris,
a spurious warning is printed after each tested layout. The output
looks like this:

Testing ../../src/../lib/layouts/AEA.layout...
../../src/tests/test_layout: !: not found
Testing ../../src/../lib/layouts/IEEEtran-CompSoc.layout...
../../src/tests/test_layout: !: not found

I have not investigated, but I think this is due to some script assuming
that /bin/sh is really /bin/bash, and this is not true on solaris.
Incidentally, for this same reason I cannot simply run ./autogen.sh
but have to run bash autogen.sh. This is really minor, though, as


Testing ../../src/../lib/layouts/tufte-handout.layout...
../../src/tests/test_layout: !: not found

layout tests passed.


-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 12:04:50PM +0200, Stephan Witt wrote:
> 
> I'll try to get it running on Linux to see how it works there. Meanwhile,
> I'm interested in comments.

Please, don't pass back and forth QPixmap objects on the stack. These
are big objects, potentially. Instead, use

bool getPixmap(QString const & path, QPixmap & pm)
{
// deal with QPixmap

return !pm.isNull();
}

> 
> diff --git a/src/frontends/qt4/GuiApplication.cpp 
> b/src/frontends/qt4/GuiApplication.cpp
> index eaf33c4..de4569a 100644
> --- a/src/frontends/qt4/GuiApplication.cpp
> +++ b/src/frontends/qt4/GuiApplication.cpp
> @@ -569,22 +569,39 @@ QString iconName(FuncRequest const & f, bool unknown)
>   return QString();
>  }
>  
> -QPixmap getPixmap(QString const & path, QString const & name, QString const 
> & ext)
> +QPixmap getPixmap(QString const & path)
>  {
>   QPixmap pixmap;
> + if (pixmap.load(path)) {
> + if (path.endsWith(".svgz") || path.endsWith(".svg") ) {
> + GuiApplication const * guiApp = theGuiApp();
> + if (guiApp != 0) {
> + 
> pixmap.setDevicePixelRatio(guiApp->pixelRatio());
> + }
> + }
> + return pixmap;
> + }
> + return QPixmap();
> +}
> +
> +QPixmap getPixmap(QString const & path, QString const & name, QString const 
> & ext)
> +{
>   QString imagedir = path;
>   FileName fname = imageLibFileSearch(imagedir, name, ext, 
> theGuiApp()->imageSearchMode());
>   QString fpath = toqstr(fname.absFileName());
> + QPixmap pixmap = getPixmap(fpath);
>  
> - if (pixmap.load(fpath)) {
> + if (!pixmap.isNull()) {
>   return pixmap;
> - } else {
> - QStringList exts = ext.split(",");
> - fpath = ":/" + path + name + ".";
> - for (int i = 0; i < exts.size(); ++i) {
> - if (pixmap.load(fpath + exts.at(i)))
> + }
> + 
> + QStringList exts = ext.split(",");
> + fpath = ":/" + path + name + ".";
> + for (int i = 0; i < exts.size(); ++i) {
> + pixmap = getPixmap(fpath + exts.at(i));
> + if (!pixmap.isNull()) {
>   return pixmap;
> - }
> + }
>   }
>  
>   bool const list = ext.contains(",");
> @@ -613,13 +630,13 @@ QIcon getIcon(FuncRequest const & f, bool unknown)
>   return QIcon();
>  
>   //LYXERR(Debug::GUI, "Found icon: " << icon);
> - QPixmap pm;
> - if (!pm.load(icon)) {
> + QPixmap pixmap = getPixmap(icon);
> + if (pixmap.isNull()) {
>   LYXERR0("Cannot load icon " << icon << " please verify resource 
> system!");
>   return QIcon();
>   }
>  
> - return QIcon(pm);
> + return QIcon(pixmap);
>  }
>  
>  

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
> 
> Thank you. The current splash has a size of 400x250. I'll attach the
> 1600x1000 splash banner to test.
> It would be great if this is ok too. If not I have to get it right myself.

Why is this (compressed) svg image so big? Are you sure there is no
embedded bitmap? That would defeat the purpose of using the svg format.

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 04:31:05PM +0200, Stephan Witt wrote:
> 
> This results in the following patch - if you had something like that in
> mind I'll split it in two patches. The other getPixmap method with
> QPixmap result was already there.

Yes, I think that it is better passing big objects by reference rather
than by value.

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 04:58:24PM +0200, Stephan Witt wrote:

> Am 15.05.2015 um 16:48 schrieb Enrico Forestieri <for...@lyx.org>:
> 
> > On Fri, May 15, 2015 at 04:31:05PM +0200, Stephan Witt wrote:
> >> 
> >> This results in the following patch - if you had something like that in
> >> mind I'll split it in two patches. The other getPixmap method with
> >> QPixmap result was already there.
> > 
> > Yes, I think that it is better passing big objects by reference rather
> > than by value.
> 
> But this is not a good property of C++ compilers than.
> 1. It's not a constant fact if an object is big.
> 2. The compiler should generate fast code for this scenario too.
> 3. This results in hard to read code eventually.

You are probably right and it seems people prefer the simpler approach by
relying on the return value optimization performed by modern compilers.
http://stackoverflow.com/questions/753312/returning-large-objects-in-functions
http://stackoverflow.com/questions/4809120/creating-and-returning-a-big-object-from-a-function
http://stackoverflow.com/questions/24685054/how-do-c-functions-return-a-big-object-or-a-structure

What triggered my comment was seeing that call in a loop, so you could simply
limit the change to that one function and leave the rest as is. Or you could
also disregard that comment ;-)

-- 
Enrico

Re: 2.2

[Enrico Forestieri]

On Fri, May 15, 2015 at 03:45:28PM +0200, Stephan Witt wrote:

> Am 15.05.2015 um 15:14 schrieb Enrico Forestieri <for...@lyx.org>:
> 
> > On Fri, May 15, 2015 at 02:53:22PM +0200, Enrico Forestieri wrote:
> >> On Fri, May 15, 2015 at 12:42:01PM +0200, Stephan Witt wrote:
> >>> 
> >>> Thank you. The current splash has a size of 400x250. I'll attach the
> >>> 1600x1000 splash banner to test.
> >>> It would be great if this is ok too. If not I have to get it right myself.
> >> 
> >> Why is this (compressed) svg image so big? Are you sure there is no
> >> embedded bitmap? That would defeat the purpose of using the svg format.
> > 
> > Indeed, I found the attached 4 (base64 encoded) bitmaps embedded in the svg.
> > That's bad.
> 
> Yes, Jürgen said it would be great to find someone who is able to do it 
> better.
> This one was made to have some SVG banner.

Sorry, I did not realize it was that same banner. But why did you attach it, 
then?

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Fri, May 15, 2015 at 09:06:34PM +0200, Georg Baum wrote:
> 
> Can you try again pelase? c_str() was not instantiated explicitly (because 
> on linux it is automatically instantiated).

Yes, it now compiles on both solaris and cygwin. However, on solaris,
a spurious warning is printed after each tested layout. The output
looks like this:

Testing ../../src/../lib/layouts/AEA.layout...
../../src/tests/test_layout: !: not found
Testing ../../src/../lib/layouts/IEEEtran-CompSoc.layout...
../../src/tests/test_layout: !: not found

I have not investigated, but I think this is due to some script assuming
that /bin/sh is really /bin/bash, and this is not true on solaris.
Incidentally, for this same reason I cannot simply run ./autogen.sh
but have to run "bash autogen.sh". This is really minor, though, as


Testing ../../src/../lib/layouts/tufte-handout.layout...
../../src/tests/test_layout: !: not found

layout tests passed.


-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Thu, May 14, 2015 at 09:09:57PM +0200, Georg Baum wrote:
 Enrico Forestieri wrote:
 
  $ cd build
  $ make alltests
  ...
CXXLD  check_trivstring
  Undefined   first referenced
   symbol in file
  _ZNK3lyx14trivial_stringIcE5c_strEv check_trivstring.o
  _ZNK3lyx14trivial_stringIwE5c_strEv check_trivstring.o
  ld: fatal: Symbol referencing errors. No output written to
  check_trivstring make[5]: *** [check_trivstring] Error 1
  make[5]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
  make[4]: *** [check-am] Error 2
  make[4]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
  make[3]: *** [check] Error 2
  make[3]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
  make[2]: *** [check-recursive] Error 1
  make[2]: Leaving directory `/opt/src/lyx/lyx-devel/build/src'
  make[1]: *** [check] Error 2
  make[1]: Leaving directory `/opt/src/lyx/lyx-devel/build/src'
  make: *** [check-recursive] Error 1
 
 This is strange. Can you post the full linker command line please?

Sure. This is on Solaris:

g++ -fPIC -O2-L/usr/local/lib -Wl,-R/usr/local/lib -L/opt/lib 
-Wl,-R/opt/lib -L/usr/X11/lib -Wl,-R/usr/X11/lib  -o check_trivstring 
check_trivstring.o dummy_functions.o boost.o liblyxsupport.a -liconv 
../../boost/liblyxboost.a -L/opt/qt5/lib -lQt5Core-laspell  -liconv -lz 
-lmagic
Undefined   first referenced
 symbol in file
_ZNK3lyx14trivial_stringIcE5c_strEv check_trivstring.o
_ZNK3lyx14trivial_stringIwE5c_strEv check_trivstring.o
ld: fatal: Symbol referencing errors. No output written to check_trivstring
make[5]: *** [check_trivstring] Error 1


but it is more clear on Cygwin:

g++ -O2-L/usr/local/lib -shared-libgcc -o check_trivstring.exe 
check_trivstring.o dummy_functions.o boost.o liblyxsupport.a -liconv 
../../boost/liblyxboost.a -L/usr/local/qt5/lib -L/usr/lib/w32api 
-L/usr/local/lib -lQt5Core -lole32 -luuid -ladvapi32 -lshell32 -luser32 
-lkernel32 -liconv -lspawn -lz -licui18n -licuuc -licudata -lpcre16 -lm  
-lshlwapi -laspell -lgdi32  -liconv -lz -lmagic
check_trivstring.o:check_trivstring.cpp:(.text+0xef): undefined reference to 
`lyx::trivial_stringchar::c_str() const'
check_trivstring.o:check_trivstring.cpp:(.text+0x1a47): undefined reference to 
`lyx::trivial_stringunsigned int::c_str() const'
collect2: error: ld returned 1 exit status
Makefile:570: recipe for target 'check_trivstring.exe' failed
make[5]: *** [check_trivstring.exe] Error 1

-- 
Enrico

Re: layout tests are failing

[Enrico Forestieri]

On Thu, May 14, 2015 at 09:23:49PM +0200, Georg Baum wrote:
 The reason is that
 
 LayoutFile const  f = l[i];
 
 in check_layout.cpp asserts. This is strange, since directly above a test is 
 made whether i is valid.
 
 Does anybody else see this?

Sorry, I cannot run the tests so I could not see this but I know why it
happens. Now addLocalLayout() returns a full path if a local layout file
is found. Hence, it has to be stripped before being used as an index.
Should be fixed now.

-- 
Enrico

Re: [LyX/master] Take into account compressed documents when creating a LyX archive

[Enrico Forestieri]

On Thu, May 14, 2015 at 07:09:17PM -0400, Richard Heck wrote:
 On 05/14/2015 12:58 PM, Enrico Forestieri wrote:
 commit a365e696e26c7ea51283ee6659457e8a6a146474
 Author: Enrico Forestieri for...@lyx.org
 Date:   Thu May 14 18:57:56 2015 +0200
 
  Take into account compressed documents when creating a LyX archive
 
 Also for stable?

Done.

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Thu, May 14, 2015 at 01:15:23PM +0200, Kornel Benko wrote:
 Am Donnerstag, 14. Mai 2015 um 12:25:01, schrieb Enrico Forestieri 
 for...@lyx.org
  On Thu, May 14, 2015 at 10:37:17AM +0200, Kornel Benko wrote:
   Am Donnerstag, 14. Mai 2015 um 01:03:17, schrieb Enrico Forestieri 
   for...@lyx.org
commit 7144f8dad84b5b321f7c87143efec9eb2b6195dc
Author: Enrico Forestieri for...@lyx.org
Date:   Thu May 14 01:02:37 2015 +0200

Update tex2lyx and tests after 306b136c
   
   Tests which are calling runtests.py with parameter 'uselyx2lyx' are 
   failing
   now if testing is not used in in the src directory.
  
  Sorry, I have no idea of what you are talking about. When I follow the
  directions in lib/doc/Development.lyx:
  
  $ cd build/src/tex2lyx
  $ make alltests
 
 This does not cover all tex2lyx tests used under cmake.
 I made a patch which works for me, under the assumption that the
 line 4 contains '\origin'. Will it stay that way?

Well, until the next file format change...

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Thu, May 14, 2015 at 12:25:01PM +0200, Enrico Forestieri wrote:
 On Thu, May 14, 2015 at 10:37:17AM +0200, Kornel Benko wrote:
  Am Donnerstag, 14. Mai 2015 um 01:03:17, schrieb Enrico Forestieri 
  for...@lyx.org
   commit 7144f8dad84b5b321f7c87143efec9eb2b6195dc
   Author: Enrico Forestieri for...@lyx.org
   Date:   Thu May 14 01:02:37 2015 +0200
   
   Update tex2lyx and tests after 306b136c
  
  Tests which are calling runtests.py with parameter 'uselyx2lyx' are failing
  now if testing is not used in in the src directory.
 
 Sorry, I have no idea of what you are talking about. When I follow the
 directions in lib/doc/Development.lyx:
 
 $ cd build/src/tex2lyx
 $ make alltests
 ...
 [lot of output]
 ...
 =
 tex2lyx tests passed.
 =

While:

$ cd build
$ make alltests
...
  CXXLD  check_trivstring
Undefined   first referenced
 symbol in file
_ZNK3lyx14trivial_stringIcE5c_strEv check_trivstring.o
_ZNK3lyx14trivial_stringIwE5c_strEv check_trivstring.o
ld: fatal: Symbol referencing errors. No output written to check_trivstring
make[5]: *** [check_trivstring] Error 1
make[5]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
make[4]: *** [check-am] Error 2
make[4]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
make[3]: *** [check] Error 2
make[3]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/opt/src/lyx/lyx-devel/build/src'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/opt/src/lyx/lyx-devel/build/src'
make: *** [check-recursive] Error 1

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Thu, May 14, 2015 at 10:37:17AM +0200, Kornel Benko wrote:
 Am Donnerstag, 14. Mai 2015 um 01:03:17, schrieb Enrico Forestieri 
 for...@lyx.org
  commit 7144f8dad84b5b321f7c87143efec9eb2b6195dc
  Author: Enrico Forestieri for...@lyx.org
  Date:   Thu May 14 01:02:37 2015 +0200
  
  Update tex2lyx and tests after 306b136c
 
 Tests which are calling runtests.py with parameter 'uselyx2lyx' are failing
 now if testing is not used in in the src directory.

Sorry, I have no idea of what you are talking about. When I follow the
directions in lib/doc/Development.lyx:

$ cd build/src/tex2lyx
$ make alltests
...
[lot of output]
...
=
tex2lyx tests passed.
=

 runtests.py:
   create test.lyx1.lyx and test.lyx2.lyx with
   # $tex2lyxexe -roundtrip -copyfiles -f $srcdir/test.ltx 
 $workdir/test.lyx
   # $lyxexe -E lyx $workdir/test.lyx1.lyx $srcdir/test.lyx.lyx
   # $lyxexe -E lyx $workdir/test.lyx2.lyx $workdir/test.lyx
 
 The created files e.g. test.lyx1.lyx and test.lyx2.lyx differ now in in the 
 origin line:
   -\origin $srcdir/
   +\origin $workdir/
 
 
 So, the routine at runtests.py:26
   def compareLyx(lines1, lines2):
 
 should be adapted too.
 
   Kornel



-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Thu, May 14, 2015 at 10:37:17AM +0200, Kornel Benko wrote:
> Am Donnerstag, 14. Mai 2015 um 01:03:17, schrieb Enrico Forestieri 
> <for...@lyx.org>
> > commit 7144f8dad84b5b321f7c87143efec9eb2b6195dc
> > Author: Enrico Forestieri <for...@lyx.org>
> > Date:   Thu May 14 01:02:37 2015 +0200
> > 
> > Update tex2lyx and tests after 306b136c
> 
> Tests which are calling runtests.py with parameter 'uselyx2lyx' are failing
> now if testing is not used in in the src directory.

Sorry, I have no idea of what you are talking about. When I follow the
directions in lib/doc/Development.lyx:

$ cd build/src/tex2lyx
$ make alltests
...
[lot of output]
...
=
tex2lyx tests passed.
=

> runtests.py:
>   create test.lyx1.lyx and test.lyx2.lyx with
>   # $tex2lyxexe -roundtrip -copyfiles -f $srcdir/test.ltx 
> $workdir/test.lyx
>   # $lyxexe -E lyx $workdir/test.lyx1.lyx $srcdir/test.lyx.lyx
>   # $lyxexe -E lyx $workdir/test.lyx2.lyx $workdir/test.lyx
> 
> The created files e.g. test.lyx1.lyx and test.lyx2.lyx differ now in in the 
> origin line:
>   -\origin $srcdir/
>   +\origin $workdir/
> 
> 
> So, the routine at runtests.py:26
>   def compareLyx(lines1, lines2):
> 
> should be adapted too.
> 
>   Kornel



-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Thu, May 14, 2015 at 12:25:01PM +0200, Enrico Forestieri wrote:
> On Thu, May 14, 2015 at 10:37:17AM +0200, Kornel Benko wrote:
> > Am Donnerstag, 14. Mai 2015 um 01:03:17, schrieb Enrico Forestieri 
> > <for...@lyx.org>
> > > commit 7144f8dad84b5b321f7c87143efec9eb2b6195dc
> > > Author: Enrico Forestieri <for...@lyx.org>
> > > Date:   Thu May 14 01:02:37 2015 +0200
> > > 
> > > Update tex2lyx and tests after 306b136c
> > 
> > Tests which are calling runtests.py with parameter 'uselyx2lyx' are failing
> > now if testing is not used in in the src directory.
> 
> Sorry, I have no idea of what you are talking about. When I follow the
> directions in lib/doc/Development.lyx:
> 
> $ cd build/src/tex2lyx
> $ make alltests
> ...
> [lot of output]
> ...
> =
> tex2lyx tests passed.
> =

While:

$ cd build
$ make alltests
...
  CXXLD  check_trivstring
Undefined   first referenced
 symbol in file
_ZNK3lyx14trivial_stringIcE5c_strEv check_trivstring.o
_ZNK3lyx14trivial_stringIwE5c_strEv check_trivstring.o
ld: fatal: Symbol referencing errors. No output written to check_trivstring
make[5]: *** [check_trivstring] Error 1
make[5]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
make[4]: *** [check-am] Error 2
make[4]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
make[3]: *** [check] Error 2
make[3]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/opt/src/lyx/lyx-devel/build/src'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/opt/src/lyx/lyx-devel/build/src'
make: *** [check-recursive] Error 1

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Thu, May 14, 2015 at 01:15:23PM +0200, Kornel Benko wrote:
> Am Donnerstag, 14. Mai 2015 um 12:25:01, schrieb Enrico Forestieri 
> <for...@lyx.org>
> > On Thu, May 14, 2015 at 10:37:17AM +0200, Kornel Benko wrote:
> > > Am Donnerstag, 14. Mai 2015 um 01:03:17, schrieb Enrico Forestieri 
> > > <for...@lyx.org>
> > > > commit 7144f8dad84b5b321f7c87143efec9eb2b6195dc
> > > > Author: Enrico Forestieri <for...@lyx.org>
> > > > Date:   Thu May 14 01:02:37 2015 +0200
> > > > 
> > > > Update tex2lyx and tests after 306b136c
> > > 
> > > Tests which are calling runtests.py with parameter 'uselyx2lyx' are 
> > > failing
> > > now if testing is not used in in the src directory.
> > 
> > Sorry, I have no idea of what you are talking about. When I follow the
> > directions in lib/doc/Development.lyx:
> > 
> > $ cd build/src/tex2lyx
> > $ make alltests
> 
> This does not cover all tex2lyx tests used under cmake.
> I made a patch which works for me, under the assumption that the
> line 4 contains '\origin'. Will it stay that way?

Well, until the next file format change...

-- 
Enrico

Re: [LyX/master] Update tex2lyx and tests after 306b136c

[Enrico Forestieri]

On Thu, May 14, 2015 at 09:09:57PM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
> 
> > $ cd build
> > $ make alltests
> > ...
> >   CXXLD  check_trivstring
> > Undefined   first referenced
> >  symbol in file
> > _ZNK3lyx14trivial_stringIcE5c_strEv check_trivstring.o
> > _ZNK3lyx14trivial_stringIwE5c_strEv check_trivstring.o
> > ld: fatal: Symbol referencing errors. No output written to
> > check_trivstring make[5]: *** [check_trivstring] Error 1
> > make[5]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
> > make[4]: *** [check-am] Error 2
> > make[4]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
> > make[3]: *** [check] Error 2
> > make[3]: Leaving directory `/opt/src/lyx/lyx-devel/build/src/support'
> > make[2]: *** [check-recursive] Error 1
> > make[2]: Leaving directory `/opt/src/lyx/lyx-devel/build/src'
> > make[1]: *** [check] Error 2
> > make[1]: Leaving directory `/opt/src/lyx/lyx-devel/build/src'
> > make: *** [check-recursive] Error 1
> 
> This is strange. Can you post the full linker command line please?

Sure. This is on Solaris:

g++ -fPIC -O2-L/usr/local/lib -Wl,-R/usr/local/lib -L/opt/lib 
-Wl,-R/opt/lib -L/usr/X11/lib -Wl,-R/usr/X11/lib  -o check_trivstring 
check_trivstring.o dummy_functions.o boost.o liblyxsupport.a -liconv 
../../boost/liblyxboost.a -L/opt/qt5/lib -lQt5Core-laspell  -liconv -lz 
-lmagic
Undefined   first referenced
 symbol in file
_ZNK3lyx14trivial_stringIcE5c_strEv check_trivstring.o
_ZNK3lyx14trivial_stringIwE5c_strEv check_trivstring.o
ld: fatal: Symbol referencing errors. No output written to check_trivstring
make[5]: *** [check_trivstring] Error 1


but it is more clear on Cygwin:

g++ -O2-L/usr/local/lib -shared-libgcc -o check_trivstring.exe 
check_trivstring.o dummy_functions.o boost.o liblyxsupport.a -liconv 
../../boost/liblyxboost.a -L/usr/local/qt5/lib -L/usr/lib/w32api 
-L/usr/local/lib -lQt5Core -lole32 -luuid -ladvapi32 -lshell32 -luser32 
-lkernel32 -liconv -lspawn -lz -licui18n -licuuc -licudata -lpcre16 -lm  
-lshlwapi -laspell -lgdi32  -liconv -lz -lmagic
check_trivstring.o:check_trivstring.cpp:(.text+0xef): undefined reference to 
`lyx::trivial_string::c_str() const'
check_trivstring.o:check_trivstring.cpp:(.text+0x1a47): undefined reference to 
`lyx::trivial_string::c_str() const'
collect2: error: ld returned 1 exit status
Makefile:570: recipe for target 'check_trivstring.exe' failed
make[5]: *** [check_trivstring.exe] Error 1

-- 
Enrico

Re: layout tests are failing

[Enrico Forestieri]

On Thu, May 14, 2015 at 09:23:49PM +0200, Georg Baum wrote:
> The reason is that
> 
> LayoutFile const & f = l[i];
> 
> in check_layout.cpp asserts. This is strange, since directly above a test is 
> made whether i is valid.
> 
> Does anybody else see this?

Sorry, I cannot run the tests so I could not see this but I know why it
happens. Now addLocalLayout() returns a full path if a local layout file
is found. Hence, it has to be stripped before being used as an index.
Should be fixed now.

-- 
Enrico

Re: [LyX/master] Take into account compressed documents when creating a LyX archive

[Enrico Forestieri]

On Thu, May 14, 2015 at 07:09:17PM -0400, Richard Heck wrote:
> On 05/14/2015 12:58 PM, Enrico Forestieri wrote:
> >commit a365e696e26c7ea51283ee6659457e8a6a146474
> >Author: Enrico Forestieri <for...@lyx.org>
> >Date:   Thu May 14 18:57:56 2015 +0200
> >
> > Take into account compressed documents when creating a LyX archive
> 
> Also for stable?

Done.

-- 
Enrico

Re: [LyX/master] Update paths of included files when saving to a different folder.

[Enrico Forestieri]

On Tue, May 05, 2015 at 04:59:38PM +0200, Jürgen Spitzmüller wrote:
 2015-05-05 15:14 GMT+02:00 Jürgen Spitzmüller:
 
  2015-05-03 23:58 GMT+02:00 Enrico Forestieri:
 
  commit 8c351e32be92fca91e2dd1f9ec478d5cb1ce6c8c
  Author: Enrico Forestieri for...@lyx.org
  Date:   Sun May 3 23:55:19 2015 +0200
 
  Update paths of included files when saving to a different folder.
 
  Fixes #9528 and #5115.
 
 
  This introduces a severe problem: When saving a file with bibtex
  bibliographies without path (because they reside in the TEXMF tree), I get
  wrong relative paths that point to the working directory of the original
  file instead of just the file names.
 
  In general, I suppose this breaks with all files that make use kpathsea
  and the texmf directory.
 
 
 A probale solution would be to check whether the linked files actually
 exist in the local directory. Since LaTeX, AFAIK, prefers those to the
 TEXMF ones in that case, we can probably safely use those in that case, and
 in others do not alter the path.

I think it is better not to update the path at all if the file does not
exists at the old location, whether or not this is a bibtex database. 
I am going to commit this change after testing.

-- 
Enrico

Re: [LyX/master] Update paths of included files when saving to a different folder.

[Enrico Forestieri]

On Tue, May 05, 2015 at 04:59:38PM +0200, Jürgen Spitzmüller wrote:
> 2015-05-05 15:14 GMT+02:00 Jürgen Spitzmüller:
> 
> > 2015-05-03 23:58 GMT+02:00 Enrico Forestieri:
> >
> >> commit 8c351e32be92fca91e2dd1f9ec478d5cb1ce6c8c
> >> Author: Enrico Forestieri <for...@lyx.org>
> >> Date:   Sun May 3 23:55:19 2015 +0200
> >>
> >> Update paths of included files when saving to a different folder.
> >>
> >> Fixes #9528 and #5115.
> >>
> >>
> > This introduces a severe problem: When saving a file with bibtex
> > bibliographies without path (because they reside in the TEXMF tree), I get
> > wrong relative paths that point to the working directory of the original
> > file instead of just the file names.
> >
> > In general, I suppose this breaks with all files that make use kpathsea
> > and the texmf directory.
> >
> 
> A probale solution would be to check whether the linked files actually
> exist in the local directory. Since LaTeX, AFAIK, prefers those to the
> TEXMF ones in that case, we can probably safely use those in that case, and
> in others do not alter the path.

I think it is better not to update the path at all if the file does not
exists at the old location, whether or not this is a bibtex database. 
I am going to commit this change after testing.

-- 
Enrico

Re: Centering graphics within a table

[Enrico Forestieri]

On Mon, May 04, 2015 at 10:39:26AM +0200, Aline Gautrein wrote:

 Lyx File

Your problem is that, from the point of view of latex, a graphics is
a single box with a given baseline (irrespective of the height) and
it is aligned according to that baseline. To achieve your goal, you
have to let latex think the baseline is in the middle of the box.
This can be done in several ways. For example, placing the figure
in a parbox and accordingly adjusting the vertical alignment.
See attached example, redacted from your example document.

-- 
Enrico
#LyX 2.1 created this file. For more info see http://www.lyx.org/
\lyxformat 474
\begin_document
\begin_header
\textclass scrbook
\begin_preamble
\usepackage{chngcntr}
\usepackage{tabulary}
\counterwithin{figure}{section}
\counterwithin {table}{section}
\interfootnotelinepenalty=1
\end_preamble
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_math auto
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\float_placement t
\paperfontsize default
\spacing single
\use_hyperref true
\pdf_bookmarks true
\pdf_bookmarksnumbered false
\pdf_bookmarksopen false
\pdf_bookmarksopenlevel 1
\pdf_breaklinks false
\pdf_pdfborder false
\pdf_colorlinks false
\pdf_backref false
\pdf_pdfusetitle true
\papersize a4paper
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Standard
\begin_inset Float figure
placement tb
wide false
sideways false
status open

\begin_layout Plain Layout
\align center
\begin_inset Tabular
lyxtabular version=3 rows=3 columns=4
features rotate=0 tabularvalignment=middle tabularwidth=90text%
column alignment=center valignment=middle width=1.5cm
column alignment=center valignment=top width=0pt
column alignment=center valignment=top width=0pt
column alignment=center valignment=top width=0pt
row
cell alignment=center valignment=bottom topline=true bottomline=true 
leftline=true rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
Particle No
\end_layout

\end_inset
/cell
cell alignment=center valignment=middle topline=true bottomline=true 
rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
1
\end_layout

\end_inset
/cell
cell alignment=center valignment=middle topline=true bottomline=true 
rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
2
\end_layout

\end_inset
/cell
cell alignment=center valignment=middle topline=true bottomline=true 
rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
3
\end_layout

\end_inset
/cell
/row
row topspace=0.5cm
cell alignment=center valignment=middle bottomline=true leftline=true 
rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
Before sintering
\end_layout

\end_inset
/cell
cell alignment=center valignment=middle bottomline=true rightline=true 
usebox=none
\begin_inset Text

\begin_layout Plain Layout
\begin_inset Box Frameless
position c
hor_pos c
has_inner_box 1
inner_pos c
use_parbox 1
use_makebox 0
width 20text%
special none
height 1in
height_special totalheight
status open

\begin_layout Plain Layout
\begin_inset Graphics
filename Kapitel 3/Bilder/Nanopartikel PVP unges.jpg
lyxscale 30
width 20text%
clip

\end_inset


\end_layout

\end_inset


\end_layout

\end_inset
/cell
cell alignment=center valignment=middle bottomline=true rightline=true 
usebox=none
\begin_inset Text

\begin_layout Plain Layout
\begin_inset Box Frameless
position c
hor_pos c
has_inner_box 1
inner_pos c
use_parbox 1
use_makebox 0
width 20col%
special none
height 1in
height_special totalheight
status open

\begin_layout Plain Layout
\begin_inset Graphics
filename Kapitel 3/Bilder/Nanopartikel NH2 unges.jpg
lyxscale 30
width 20text%

\end_inset


\end_layout

\end_inset


\end_layout

\end_inset
/cell
cell alignment=center valignment=middle bottomline=true rightline=true 
usebox=none
\begin_inset Text

Re: Centering graphics within a table

[Enrico Forestieri]

On Mon, May 04, 2015 at 11:36:26AM +0200, Jürgen Spitzmüller wrote:

 2015-05-04 10:39 GMT+02:00 Aline Gautrein:
 
  Lyx File
 
 
 Graphic files are missing.

They are not relevant. Replace them with \rule{0.2\textwidth}{2cm}
in ERT. See attached original and redacted example.

-- 
Enrico
#LyX 2.1 created this file. For more info see http://www.lyx.org/
\lyxformat 474
\begin_document
\begin_header
\textclass scrbook
\begin_preamble
\usepackage{chngcntr}
\usepackage{tabulary}
\counterwithin{figure}{section}
\counterwithin {table}{section}
\interfootnotelinepenalty=1
\end_preamble
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_math auto
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\float_placement t
\paperfontsize default
\spacing single
\use_hyperref true
\pdf_bookmarks true
\pdf_bookmarksnumbered false
\pdf_bookmarksopen false
\pdf_bookmarksopenlevel 1
\pdf_breaklinks false
\pdf_pdfborder false
\pdf_colorlinks false
\pdf_backref false
\pdf_pdfusetitle true
\papersize a4paper
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Standard
\begin_inset Float figure
placement tb
wide false
sideways false
status open

\begin_layout Plain Layout
\align center
\begin_inset Tabular
lyxtabular version=3 rows=3 columns=4
features rotate=0 tabularvalignment=middle tabularwidth=90text%
column alignment=center valignment=middle width=1.5cm
column alignment=center valignment=top width=0pt
column alignment=center valignment=top width=0pt
column alignment=center valignment=top width=0pt
row
cell alignment=center valignment=bottom topline=true bottomline=true 
leftline=true rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
Particle No
\end_layout

\end_inset
/cell
cell alignment=center valignment=middle topline=true bottomline=true 
rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
1
\end_layout

\end_inset
/cell
cell alignment=center valignment=middle topline=true bottomline=true 
rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
2
\end_layout

\end_inset
/cell
cell alignment=center valignment=middle topline=true bottomline=true 
rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
3
\end_layout

\end_inset
/cell
/row
row topspace=0.5cm
cell alignment=center valignment=middle bottomline=true leftline=true 
rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
Before sintering
\end_layout

\end_inset
/cell
cell alignment=center valignment=middle bottomline=true rightline=true 
usebox=none
\begin_inset Text

\begin_layout Plain Layout
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
rule{0.2
\backslash
textwidth}{2cm}
\end_layout

\end_inset


\end_layout

\end_inset
/cell
cell alignment=center valignment=middle bottomline=true rightline=true 
usebox=none
\begin_inset Text

\begin_layout Plain Layout
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
rule{0.2
\backslash
textwidth}{2cm}
\end_layout

\end_inset


\end_layout

\end_inset
/cell
cell alignment=center valignment=middle bottomline=true rightline=true 
usebox=none
\begin_inset Text

\begin_layout Plain Layout
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
rule{0.2
\backslash
textwidth}{2cm}
\end_layout

\end_inset


\end_layout

\end_inset
/cell
/row
row topspace=default
cell alignment=center valignment=middle bottomline=true leftline=true 
rightline=true usebox=none
\begin_inset Text

\begin_layout Plain Layout
After sintering
\end_layout

\end_inset
/cell
cell alignment=center valignment=middle bottomline=true rightline=true 
usebox=none
\begin_inset Text

\begin_layout Plain Layout
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
rule{0.2
\backslash
textwidth}{2cm}
\end_layout

\end_inset


\end_layout

\end_inset
/cell
cell alignment=center valignment=middle bottomline=true 

Re: Relative paths

[Enrico Forestieri]

On Mon, May 04, 2015 at 03:42:32PM +0200, Jean-Marc Lasgouttes wrote:

 Le 04/05/2015 00:44, Enrico Forestieri a écrit :
 Unless someone can give an example showing that a relative path of one
 of the above forms produces problems, I am going to unify the two
 methods in a single one simply returning a relative path.
 
 Using relative paths is a superior alternative to absolute ones, but
 currently LyX can return an absolute path when a relative one is
 actually possible.
 
 A relative path is always possible, at least in linux: think
   ../../home/foo/myfiles/foo.lyx
 which is actually an absolute path to a file in another user's homedir.

Wrong example. The relative path would be ../foo/myfiles/foo.lyx (but
see below).

 The idea was to return a relative path only when the file is strictly up
 (resp. down) in the directory tree. Note that this relative path is just an
 indication and that the user is free to replace it with something else in
 the relevant dialogs (at least in the cases I know of).
 
 Now, what is the argument why it is wrong? I had problems following the
 various threads on my phone.

Nothing wrong if you always work on the same computer and do not
collaborate with others. The way LyX deals with relative paths is
an arbitrary obstacle to collaborative work. If all paths were
relative, I could make an archive starting from root (/) like this:

usr/local/texfiles/.
home/user/figs/
home/user/docs/...


pass it to a Windows or Mac user, who simply has to unpack it on *any*
subtree on his computer and start working on LyX documents.
When he is done, he has to simply pack that subtree and pass it back.
But LyX, stubbornly insists in not using relative paths in certain
cases based on an arbitrary decision.

-- 
Enrico