Re: document class with landscape orientation

[Guenter Milde]

On 2016-09-23, Guenter Milde wrote:
> Dear LyX-developers,

> is there a layout key/value to tell LyX that a document class (or package)
> uses paper orientation "landscape" as default?

> Currently, seminar requires custom options for paper orientation switch:

>orientation   LyX writes  seminar expects
>  ==  

>landscape landscape   

>portrait portrait

This is now http://www.lyx.org/trac/ticket/10398

Thanks,

Günter

Re: [LyX/master] Sort the language nesting mess with polyglossia

[Guillaume Munch]

Le 24/09/2016 à 03:25, Enrico Forestieri a écrit :

commit 3bc08a76c42cd350a3141f00f37082bc9fab8967
Author: Enrico Forestieri 
Date:   Sat Sep 24 03:15:02 2016 +0200

Sort the language nesting mess with polyglossia

When using polyglossia, lyx was making a real mess when changing
language inside nested insets. The \begin{language} and
\end{language} commands were not well paired such that they could
easily occur just before and after the start or end of an
environment. Of course this was causing latex errors such that
"\begin{otherlanguage} ended by \end{environment}".
There may still be some cases I did not take into account.


Hi, this commit introduced the following new warning in master with the 
default gcc configuration:


../../src/output_latex.cpp: In function ‘void lyx::TeXOnePar(const 
lyx::Buffer&, const lyx::Text&, lyx::pit_type, lyx::otexstream&, const 
lyx::OutputParams&, const string&, int, int)’:
../../src/output_latex.cpp:986:7: warning: suggest parentheses around 
‘&&’ within ‘||’ [-Wparentheses]

   && nextpar->getDepth() == par.getDepth()
   ^

Re: Regular expression search

[Kornel Benko]

Am Montag, 26. September 2016 um 19:06:58, schrieb Kornel Benko 
> 
> The test keytest/findadv-05 shows a new error.
> 
> (Repeating commands from the test case)
> 1.) Open new document
> 2.) write 'foo foo foo foo'
> 3.) make the middle 2 foo's be italic
> 4.) move cursor to HOME position
> 5.) open the advanced search dialog
> 6.) go to 'Settings' part of the dialog
> 7.) uncheck 'Ignore format'
> 8.) go back to 'Search' part of the dialog
> 9.) in the 'Find' field enter 'foo' in italic
> 10.) click on 'Find Next'
> 
> italic (or slanted) foo is not found. Using 'foo foo' as search pattern works.
> Try to make the 'space' between 'foo foo' be normal (e.g not italic)
> Now searching for 'foo' will find the first 'foo' but not the second.
> 

I tried to bisect, but to my surprise could not find the associated commit.
The only difference was that for bisecting I used another compiler (gcc 4.8.4),
while I otherwise use the version 6.1.0.

So I rebuild lyx with gcc4.8, the error is gone.

Now trying with gcc5.3 ... error.

What are the differences between gcc5.3, 6.1 and 4.8?
gcc4.8  Compiler does not support std_regex, flag = "--std=c++11"
gcc5.3  Compiler supports std_regex, flag = "--std=c++14"
gcc6.1  Compiler supports std_regex, flag = "--std=c++14"

Kornel

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

Inkscape

[Vermeer Martin]

Yes I missed it, thanks.

The non-scaling is intentional, as explained in the external-templates comment. 
Fonts are scaled to the surrounding text (unlike with XFig), a property that 
allowing rescaling here would destroy. Rescaling should rather be done inside 
Inkscape, by actually rescaling the figure. But sure, it could be enabled and 
the responsibility left  to the user.

About the preview inset, I think I just don't understand the logic here well 
enough (and I don't use preview as it's heavy on the CPU with large docs), but 
if you can make the necessary change (and if it's simple) just make it and go 
ahead. 

Yes, I would like to see this checked in.

Best, Martin

From: Guillaume Munch [g...@lyx.org]
Sent: Wednesday, September 28, 2016 1:45 AM
To: Vermeer Martin
Subject: Fwd: Re: Inkscape /LyX integration (working!)

Hi, I am forwarding to you this message sent to the lyx-devel list last
week in case you missed it.


 Message transféré 
Sujet : Re: Inkscape /LyX integration (working!)
Date : Wed, 21 Sep 2016 23:51:13 +0200
De : Guillaume Munch 
Pour : lyx-devel@lists.lyx.org
Groupes de discussion : gmane.editors.lyx.devel
Références :
<4a4a9e56a391a1479fbe21e7590e45fcac501...@exmdb07.org.aalto.fi>
<20160831223720.ga9...@atrey.karlin.mff.cuni.cz>
<4a4a9e56a391a1479fbe21e7590e45fc010c6ae...@exmdb07.org.aalto.fi>
<4a4a9e56a391a1479fbe21e7590e45fc010c6b0...@exmdb07.org.aalto.fi>
<20160905183545.gc9...@atrey.karlin.mff.cuni.cz>
<4a4a9e56a391a1479fbe21e7590e45fc010c6b1...@exmdb07.org.aalto.fi>

Le 06/09/2016 à 05:48, Vermeer Martin a écrit :
> Pavel thanks!
>
> Attached the changes you proposed (though still to HEAD).
>
> Yes, the Inkscape bug is known upstream. Fixing seems to be a bit tricky as 
> it is due to a change in the Cairo library, aimed at enabling the output of 
> "layers", transparent or not, covering or covered by text strings. But of 
> course Inkscape should know itself how many PDF pages it is outputting...
>
> Someone please push if this passes muster
>


Hi Martin,

I have rebased your patches against master and it works.

One thing I have noticed is that the preview provided by the external
inset does not update when one changes the surrounding text. For
instance the preview can fail because of a missing package and it will
not update after correcting the preamble, or it will not reflect the
surrounding font. In practice it works much better to wrap the
ExternalInset in a preview inset, which takes the surroundings into
account for updating the preview.

Also, is it possible to enable the resizing options from the dialog?

Do you want me to commit the patches?


Guillaume

ctests: inputencoding tests

[Guenter Milde]

Dear Kornel,

the current tests do not include non-default input encoding.

IMV, testing export with inputencodings "utf8" and "ascii" would help to
find several hidden bugs and make LyX more robust.

* While the inputencoding is not important as long as the *.tex file is only
  temporary, "utf8" and "ascii" have use cases
  
  * when exporting to LaTeX (collaboration, archivation)
  * for debugging
  
  LyX's default "mixed language specific input encodings" is especially
  unsuitable in these situations.

* Some Babel-languages expect "utf8" as default, 
  e.g. Babel-Russian recommends utf8 since several years.
  LyX still uses koi8-r because switching to "utf8" without
  previous tests is too riscy.
  
* Testing "ascii" would allow us to separate problems due to the XeTeX
  engine from encoding problems for failures of ".*pdf4_texF".
  
* With stable and tested export to utf8-encoded LaTeX files, this could also
  become a default for Latin-script based languages.
  
  
I expect the tests to uncover some problems similar to what we have seen
with XeTeX-texF.

There is no need to test this with all export formats, it would suffice to
test with pdflatex (pf2), say.


What do you think?


Günter

Re: [LyX/master] Sort the language nesting mess with polyglossia

[Enrico Forestieri]

On Tue, Sep 27, 2016 at 01:02:04PM +0200, Guillaume Munch wrote:
> Le 24/09/2016 à 03:25, Enrico Forestieri a écrit :
> >commit 3bc08a76c42cd350a3141f00f37082bc9fab8967
> >Author: Enrico Forestieri 
> >Date:   Sat Sep 24 03:15:02 2016 +0200
> >
> >Sort the language nesting mess with polyglossia
> >
> >When using polyglossia, lyx was making a real mess when changing
> >language inside nested insets. The \begin{language} and
> >\end{language} commands were not well paired such that they could
> >easily occur just before and after the start or end of an
> >environment. Of course this was causing latex errors such that
> >"\begin{otherlanguage} ended by \end{environment}".
> >There may still be some cases I did not take into account.
> 
> Hi, this commit introduced the following new warning in master with the
> default gcc configuration:
> 
> ../../src/output_latex.cpp: In function ‘void lyx::TeXOnePar(const
> lyx::Buffer&, const lyx::Text&, lyx::pit_type, lyx::otexstream&, const
> lyx::OutputParams&, const string&, int, int)’:
> ../../src/output_latex.cpp:986:7: warning: suggest parentheses around ‘&&’
> within ‘||’ [-Wparentheses]
>&& nextpar->getDepth() == par.getDepth()
>^

Thanks. Fixed at f476d9c8.

-- 
Enrico

Re: [LyX/master] ctests: update labeling patterns.

[Guenter Milde]

On 2016-09-23, Kornel Benko wrote:
> Am Freitag, 23. September 2016 um 07:29:14, schrieb Guenter Milde 
> 

...

> If we could considerably reduce the number of failings, we can also
> omit regexes and instead use full test names.

1. We cannot significantly reduce the number of failings.

   This may have worked for the original ~300 test cases but now we have
   5407. Even with the same failure-rate we would get 10 times more
   problematic cases.
   
   In addition, there is a large number of failing exports due to the
   non-standard export routes tested but not supported by LaTeX for
   several packages and document classes. (We may ignore them if we do
   not expect future support.)
   See below for statistics.

2. Full test names would not solve the problem of a test case with two (or
   more) problems making it both, unreliable and failing.

> Yes, unfortunately we cannot make tests selective to specific failure.

There is also no need to do this.

However, we could create independent labels for unreliable and inverted
tests or just "allow" matches in both files (actually, there is nothing in
the documentation telling that this is not allowed).


Statistics:

Currently, we have 265 problematic tests 
(ctest -N -L "inverted|suspended|unreliable")

146 tests that are known to fail, including

 57 tests requiring attention -L todo
 14 tests with a track number -L lyxbugs
 61 tests we cannot fix   -L texissues
 
119 unreliable tests, including
 
 62 tests with extra requirements -L nonstandard
 46 passing test with wrong output-L wrong_output
 10 with result depending on TeXLive version  -L varying_versions
 
The 57 "todo" tests are to be investigated and sorted -- only a few
of them will be "easyfix".

This means we have about 200 problematic test cases that will stay so for a
longer time and should adapt to this.

Günter

Re: ctests: inputencoding tests

[Kornel Benko]

Am Dienstag, 27. September 2016 um 20:02:26, schrieb Guenter Milde 

> Dear Kornel,
> 
> the current tests do not include non-default input encoding.
> 
> IMV, testing export with inputencodings "utf8" and "ascii" would help to
> find several hidden bugs and make LyX more robust.
> 
> * While the inputencoding is not important as long as the *.tex file is only
>   temporary, "utf8" and "ascii" have use cases
>   
>   * when exporting to LaTeX (collaboration, archivation)
>   * for debugging
>   
>   LyX's default "mixed language specific input encodings" is especially
>   unsuitable in these situations.
> 
> * Some Babel-languages expect "utf8" as default, 
>   e.g. Babel-Russian recommends utf8 since several years.
>   LyX still uses koi8-r because switching to "utf8" without
>   previous tests is too riscy.

I tried to use UTF8 for ru/Tutorial.lyx. pdf4_systemF seems to work with 
'Dejavu' fonts.
pdf4_texF does not work. That is, I don't know which tex-font should I select 
to make it working.

> * Testing "ascii" would allow us to separate problems due to the XeTeX
>   engine from encoding problems for failures of ".*pdf4_texF".
>   
> * With stable and tested export to utf8-encoded LaTeX files, this could also
>   become a default for Latin-script based languages.
>   
>   
> I expect the tests to uncover some problems similar to what we have seen
> with XeTeX-texF.
> 
> There is no need to test this with all export formats, it would suffice to
> test with pdflatex (pf2), say.
> 
> 
> What do you think?

If we can specify the encoding in the lyx-file depending on language and output 
format, then it is easy.
In some cases we already would get encodings from the language file 
'lib/languages'.
(ATM disabled)
See export.cmake:34 and useSystemFonts.pl:146.

I am open to suggestions.

> Günter
> 

Kornel

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