Re: export doc/fr/Additonal.lyx to pdf4 still fails

[Uwe Stöhr]

Am 24.11.2015 um 21:44 schrieb Georg Baum:


Noone needs to export this document with XeTeX so this may be wasted
effort.


+1


IMHO it would be a good idea to create a bug report (not demanding working
XeTeX export, but for fixing the iconv error).


Done:
http://www.lyx.org/trac/ticket/9871

thanks and regards
Uwe

file generation after compilation is always executed twice

[Uwe Stöhr]

This is a long standing and annoying problem I am facing when compiling 
LyX. When I compile LyX via CMake using "build-install" then


- the compilation of LyX and tex2lyx works fine
- the files like e.g. the gmo-files are created
- but after this is done, the files are immediately created again

So this is done always twice:

  Generating qt4_files
  Generating layouts_files
  Generating languages_files
  Generating latexfonts_files
  Generating encodings_files
  Generating ui_files
  Generating external_files
  Generating formats_files
  C:/Python27/python.exe D:/LyXGit/Master/po/lyx_pot.py -b 
D:/LyXGit/Master -o D:/LyXGit/Master/compile-result/po/qt4_l10n.pot -t 
qt4 --src_file=D:/LyXGit/Master/compile-result/po/qt4_files


this is annoying because the .gmo file creation needs some time.

Could anybody point me to the code where this execution is acidentally 
run twice?


thanks and regards
Uwe

Re: file generation after compilation is always executed twice

[Kornel Benko]

Am Mittwoch, 25. November 2015 um 00:23:32, schrieb Uwe Stöhr 
> This is a long standing and annoying problem I am facing when compiling 
> LyX. When I compile LyX via CMake using "build-install" then
> 
> - the compilation of LyX and tex2lyx works fine
> - the files like e.g. the gmo-files are created
> - but after this is done, the files are immediately created again
> 
> So this is done always twice:
> 
>Generating qt4_files
>Generating layouts_files
>Generating languages_files
>Generating latexfonts_files
>Generating encodings_files
>Generating ui_files
>Generating external_files
>Generating formats_files
>C:/Python27/python.exe D:/LyXGit/Master/po/lyx_pot.py -b 
> D:/LyXGit/Master -o D:/LyXGit/Master/compile-result/po/qt4_l10n.pot -t 
> qt4 --src_file=D:/LyXGit/Master/compile-result/po/qt4_files
> 
> this is annoying because the .gmo file creation needs some time.
> 
> Could anybody point me to the code where this execution is acidentally 
> run twice?

There is no such place I were aware of.

We call the macro GETTEXT_CREATE_TRANSLATIONS() which I 'stole' from kde 
project and adapted for lyx.
You can find it in development/cmake/modules/FindLyXGettext.cmake.

If you happen to call also the target 'update-gmo', then yes, it is called 
again.
(update-gmo creates gmo files in source, while normal creation is done in the 
build directory)

And why the creation is slow on windows I don't know.
This does not happen under linux.

> thanks and regards
> Uwe

Kornel

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

Re: Font of LyX manuals

[Uwe Stöhr]

Am 30.10.2015 um 09:08 schrieb Guenter Milde:


LyX manuals currently use user-preamble code to set the font depending on
the export route and availability:

* Latin Modern (CM-extension) with PDF(luatex), PDF(pdflatex), if lmodern.sty 
is installed


This is the only export the manuals are designed for. Latin Modern fonts 
are to my knowledge in every basic TeX distribution and can therefore be 
assumed as available.


DVI and PS as output format does not support all the features described 
in the 3 main manual files: Math, EmbeddedObjects and UserGuide
Moreover the design is to get PDF files with full functionality: 
clickable internal links, bookmarks, clickable URL and links to included 
files etc. The PDFs are also designed to print them as booklet if you 
like. (For this feature I therefore even use binding correction.)


(Btw. DVI is evil because at least with MiKTeX the DVI output from our 
docs make the built-in DVI viewer file crashing. The reason seems to be 
rotated text in the documents.)



The alternative LatinModern CM-lookalike is not guaranteed to be installed
on each system.


On which system there is no Latin Modern?


To prevent an additional dependency for compiling the
manuals, the following preamble-selection code was chosen:

   \usepackage{ifpdf} % part of the hyperref bundle
   \ifpdf % if pdflatex or lualatex is used
   \@ifpackageloaded{fontspec}{}{% non-tex-fonts default to LModern
% set fonts for nicer pdf view
\IfFileExists{lmodern.sty}{\usepackage{lmodern}}{}
   }
   \fi % end if pdflatex is used


Looks good.


* Latin Modern is the community-recommended (but not automatically used)
   "international" substitution for CM.

   + It comes with optical sizes and mixes well with the default math fonts.

   - It is too light for good on-screen reading.


I don't agree. Since years I use Latin Modern for all my documents 
including my Ph.D. thesis. My colleagues at the University liked the 
font that even Word users started to use Latin Modern as font.


Btw. Since the manuals are designed for on-screen reading I provides 
them as PDF:

http://wiki.lyx.org/LyX/DocumentationDevelopment#download

regards Uwe

Re: simple [patch] support for verbatim*

[Uwe Stöhr]

Am 24.11.2015 um 03:10 schrieb Richard Heck:


Uwe, please test that this new patch does what you want it to do. I've
tested it, but only minimally.


Many thanks.
It did not work because you output "verbatim" no matter if it was the 
starred version or not. I corrected this and put it in.



Another issue is that \verbatim* is not presently handled properly by
tex2lyx. If we are going to add verbatim* support for 2.2, then it seems
to me that we should also have tex2lyx support.


This part is also in now.


What's worse is that
tex2lyx makes a total mess of that other file I've attached.


This works fine with the patch I committed. please report back if not.

regards Uwe

Re: mhchem and Xe/LuaTeX problems

[Uwe Stöhr]

Am 22.11.2015 um 22:59 schrieb Guenter Milde:


My intention was not to separate this. chemical equations are formulas
nevertheless.


They are formulas, but not mathematical ones, so I would rather place
this in "specific manuals > Chemical Formulas".


Is this really necessary? One more file for me to maintain. Yes I am 
lazy and keeping the text where it is would help me. But if others vote 
for this change too then I'll do it of course.



However, whenever this is not in the way of the primary goal, I would like
to see the manuals also robust and clean

* as good examples for LyX use,
> * as starting point for users trying to experiment with various LyX 
settings,

>
> * as a set of sample documents for the export tests

Oh, I spent many hours in creating the 3 files EmbeddedObjects, Math and 
the UserGuide to describe so many different features. To be able to do 
this in one file with references to each other they all use a lot of 
preamble code and they are therefore no god start points.


To play with features one should create a new file and experiment with 
the particular feature one likes to play with.

I could also add a note to make this clear.

I am even a bit proud of that one can export these files as PDF and use 
this as a nicely typeset handbook of LyX with can also be printed as book.



(However, the PDF looks slightly different depending on whether the
lmodern fonts are installed or not: not only is EC pixly, but also the
letter ß looks different in CM, CM-Super, EX vs. LM.)


To my knowledge lmodern is part of every TeX installation (tested with 
MiKTeX and TeXLive). So almost every user should have LaTein Modern and 
thus get the same output.



If you like to use special fonts you can do this in your own documents.


I don't want special fonts, but fonts that are available with every standard
TeX installation in vector (type 1) format in the font encoding used in the
docs. Currently, this is not the case. We get different fonts for PS vs. PDF
(if LM is installed) and bitmap fonts for DVI,  PS and PDF(dvipdfm) PDF(ps2pdf)
as well as on sites without the optional Latin Modern fonts.


All manuals are designed to be exported as PDF (pdflatex). I could also 
add a note to make this clear.



This is why I prefer to use a font that is really available in any case and
not substituted by some other or only loaded optionally.


But this is the reason why Latin Modern is used.


But why don't you load Latin Modern for PS, DVI, PDF(ps2pdf), PDF(dvipdfm)?


Because the files are not designed for that. For example DVI does not 
support rotations (text, boxes and table cells). Some color examples 
would also be output incorrectly. Moreover on MiKTeX exporting the 
UserGuide to DVI crasheds the DVI viewer "Yap".
Some explained PDF features like bookmark entries with equations, 
special chars etc. fail/are incorrectly output in PS ad also via ps2pdf.


regards Uwe

Lower case mathcal

[Christopher Menzel]

Dear LyX folk,

Quick question — what would it take to get display support for lower case 
calligraphic letters, which you can get in your rendered PDF via a package like 
BOONDOX-cal. Currently, typing lower case letters inside a \mathcal tag in math 
mode generates a seemingly random selection of symbols. Even just being able to 
see ordinary lower case letters, even if not calligraphic, would be preferable. 
A reasonably good workaround here is to use instant preview mode, but that's 
still less than ideal.

Just wondering; this is obviously not a major problem but it would be cool if 
there was a reasonably easy fix.

Chris Menzel

ps: LyX 2.2alpha with its support for retina displays is amazingly great! Many 
thanks to Stephan Witt and the other developers for their talent and their 
commitment this truly wonderful and extraordinarily useful software.

Re: Lower case mathcal

[Richard Heck]

On 11/24/2015 02:58 PM, Christopher Menzel wrote:
> Dear LyX folk,
>
> Quick question — what would it take to get display support for lower case 
> calligraphic letters, which you can get in your rendered PDF via a package 
> like BOONDOX-cal. Currently, typing lower case letters inside a \mathcal tag 
> in math mode generates a seemingly random selection of symbols. Even just 
> being able to see ordinary lower case letters, even if not calligraphic, 
> would be preferable. A reasonably good workaround here is to use instant 
> preview mode, but that's still less than ideal.
>
> Just wondering; this is obviously not a major problem but it would be cool if 
> there was a reasonably easy fix.

I've noticed this problem, too. I'm not sure why we get the weird
symbols we do.

Richard

Re: [LyX/master] Document the export tests and other tests

[Georg Baum]

Kornel Benko wrote:

> Am Sonntag, 22. November 2015 um 19:22:42, schrieb Georg Baum
> 
> 
>> 2)
>>   - autotests/export/ for export tests (does not work with the current
>>   test
>> machinery)
> 
> It is now possible.
> All the tests there will be labeled by 'autotests' (additionally to label
> 'export').

Thank you very much! Then I'll use that (may take some days though).

> I think autotests/export is just fine. The test-names look a little scary,
> e.g. 'export/export/somefile_pdf4_texF'

I don't care about the actual test names, as long as they can be identified 
in any way, and this is the case with the labels.


Georg

Re: [LyX/master] Document the export tests and other tests

[Georg Baum]

Guenter Milde wrote:

> On 2015-11-22, Georg Baum wrote:
> 
>> 1) lib/tests/ (or any new directory not at top level) just for new
>> dedicated export tests (will cause problems in cmake if other tests than
>> export tests are added)
> 
> Don't like this, as binary LyX packages (*.deb, *.rpm) should ship with
> lib/ but not with tests.

This is not relevent for the location of the test directory anymore, but for 
completeness: lib is not simply copied into the binary packages, nor is it 
copied into the installation. There are several files in lib/ which do not 
appear in the installation. Those which are part of the source tarball are 
marked with dist_noinst_DATA in lib/Makefile.am, those which exist in git 
but are not even part of the source tar ball do not appear at all in 
lib/Makefile.am.


Georg

Re: Lower case mathcal

[Georg Baum]

Christopher Menzel wrote:

> Dear LyX folk,
> 
> Quick question — what would it take to get display support for lower case
> calligraphic letters, which you can get in your rendered PDF via a package
> like BOONDOX-cal. Currently, typing lower case letters inside a \mathcal
> tag in math mode generates a seemingly random selection of symbols. Even
> just being able to see ordinary lower case letters, even if not
> calligraphic, would be preferable. A reasonably good workaround here is to
> use instant preview mode, but that's still less than ideal.
> 
> Just wondering; this is obviously not a major problem but it would be cool
> if there was a reasonably easy fix.

Unfortunately there is no easy way. \mathcal is hardwired to the cmsy10 font 
internally in LyX. Furthermore, the symbols are addressed using the internal 
font encoding and not unicode. This is really ugly, but it works for the 
characters supported by standard LaTeX, and so far nobody volunteered to 
refactor this part of the code and make it more robust.

For those who are interested: There is a big comment in GuiPainter::text(). 
You can also search for CMSY_FAMILY in the sources.


Georg

Re: 'make check' still fails

[Richard Heck]

On 11/24/2015 02:37 PM, Georg Baum wrote:
> Scott Kostyshak wrote:
>
>> On Sun, Nov 22, 2015 at 06:40:45PM +, Guillaume Munch wrote:
>>> Le 22/11/2015 17:38, Georg Baum a écrit :
 It is now also clear that the MSVC workaround is not needed, so I
 deleted it. Is the attached patch OK to go in?
>>> Looks good (I trust that the small details are ok). I have the same
>>> understanding. Isn't the "FIXME: Unicode" trivial to fix btw?
>> I would say commit then.
> Done. To my knowledge there are no known problems with std::regex anymore.

That may mean we are ready for a second alpha.

Richard

>
>
> Georg
>

Re: export doc/fr/Additonal.lyx to pdf4 still fails

[Georg Baum]

Guenter Milde wrote:

> Dear Lyxers,
> 
> thanks to Uwe for removing the non-ASCII character from ERT in
> doc/fr/Additonal.lyx in 98746f3bda2df7d3/lyxgit.
> 
> Unfortunately, the export to XeTeX
> 
>   lyx-svn -e pdf4 Additional.lyx
>   
> still fails (error log below).
> 
> What shall we do?
> 
> * Explore and try to find a reason,
> 
> * Leave as "wontfix"
> 
> Noone needs to export this document with XeTeX so this may be wasted
> effort.
> 
> 
> Günter
> 
> 
> Error 84 returned from iconv when converting from UCS-4LE to ascii:
> Ungültiges oder unvollständiges Multi-Byte- oder Wide-Zeichen

This means that LyX gave invalid unicode to iconv when converting to ASCII. 

I think this would be worth investigating, not because export to XeTeX of 
this document is important, but because this bug may appear in other, more 
important circumstances as well: French does only need the latin1 subset of 
unicode, which is covered 100% by lib/unicodesymbols. Therefore, LyX should 
be able to export to pure ASCII. Even if that is not possible for some 
reason, it should tell the user (the "uncodable character" warning), and it 
should never ever send invalid unicode to iconv.

IMHO it would be a good idea to create a bug report (not demanding working 
XeTeX export, but for fixing the iconv error).


Georg

Re: simple [patch] support for verbatim*

[Georg Baum]

Uwe Stöhr wrote:

> Why do you want to see the obvious changes to the FORMATS file and the
> changed digits of the version? They are obvious and only cost you time
> to test the patch because you are then forced to a complete
> recompilation. (This takes here 15 min).

This is indeed too slow.

Does your machine have more than one core? Does only one cl.exe process at a 
time appear in process explorer (or task manager if you do not have process 
explorer) if you build after changing a central header such as version.h? If 
the answer to both questions is yes, add the following line to the batch 
file you use for building or starting MSVC:

set CL=/MP

After doing that, process explorer should show n cl.exe processes in 
parallel, where n is the number of cores of your machine. Of course this is 
only true if enough C++ files need to be compiled, if only one haas changed 
then of course only one cl.exe is started.

> The task is to save time - that's what I don't have. Writing 10 of these
> mails is quicker for me than forcing me to recompile LyX completely.

It saves time on your side at the cost of added time for your fellow 
developers. I think the better solution is to tackle the root problem (slow 
building), this will even save more of your time.

If you do already use parallel compilation, we could also play with 
precompiled headers, this can make a huge different in compile time with 
MSVC, but it is less easy to do.


Georg

Re: simple [patch] support for verbatim*

[Georg Baum]

Richard Heck wrote:

> I was mostly thinking that (a) if we're going to add this for 2.2, the
> tex2lyx part should also be done---the rule you quoted applies to
> mid-cycle commits and doesn't say anything about what should be done for
> a major release---and (b) that the test file I attached (a minimal
> modification of the existing one) gets totally mangled. The \verbatim*
> command isn't even output properly as ERT.

I don't think that we need to make any distinction here for mid-cycle 
commits and a major release. We do already have many LyX features that are 
imported as ERT by tex2lyx. Why should we make the hurdle for new features 
higher than for existing ones? IMHO the question is: Is the new feature 
useful for LyX? If the answer is yes, put it in.

Of course tex2lyx should either do a perfect roundtrip, or create proper ERT 
for the new feature. If it does not, then this has to be fixed. However, if 
there is a bug in tex2lyx that makes it produce invalid output for the new 
feature, which can also be triggered without the new feature, then I'd see 
this as completely independent and would even allow the new feature without 
a tex2lyx fix.


Georg

Re: simple [patch] support for verbatim*

[Richard Heck]

On 11/24/2015 03:05 PM, Georg Baum wrote:
> Of course tex2lyx should either do a perfect roundtrip, or create
> proper ERT for the new feature. If it does not, then this has to be
> fixed. However, if there is a bug in tex2lyx that makes it produce
> invalid output for the new feature, which can also be triggered
> without the new feature, then I'd see this as completely independent
> and would even allow the new feature without a tex2lyx fix

I was thinking that LyX's own support for the feature might mean the bug
becomes easier to trigger.

Richard

Re: Lower case mathcal

[Guillaume Munch]

Le 24/11/2015 19:58, Christopher Menzel a écrit :

Dear LyX folk,

Quick question — what would it take to get display support for lower
case calligraphic letters, which you can get in your rendered PDF via
a package like BOONDOX-cal. Currently, typing lower case letters
inside a \mathcal tag in math mode generates a seemingly random
selection of symbols. Even just being able to see ordinary lower case
letters, even if not calligraphic, would be preferable. A reasonably
good workaround here is to use instant preview mode, but that's still
less than ideal.


The ideal solution would be to implement support for OTF math fonts in
LyX's buffer view (essentially http://www.lyx.org/trac/ticket/9014).
Originally, showing in LyX the same as computer modern in LaTeX made
sense when the most used fonts used to behave like this. But this time
is long gone. Displaying lowercase letters even if not calligraphic
would be better meanwhile, IMO.

(I notice that the message was sent to both lists. If somebody replies,
I would advise to do so on the general list now that it has been posted
there.)



Just wondering; this is obviously not a major problem but it would be
cool if there was a reasonably easy fix.

Chris Menzel

ps: LyX 2.2alpha with its support for retina displays is amazingly
great! Many thanks to Stephan Witt and the other developers for their
talent and their commitment this truly wonderful and extraordinarily
useful software.

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Pavel Sanda]

Guillaume Munch wrote:
>> 3. General preference (not sure if document or user) for ignoring non 
>> essential
>> changes, which disturbs version control flow. Similar to 1. but it
>> would encompass e.g. CT on/off, output_changes, GUI justification.
>> I have another candidate here as well - not storing opening/closing 
>> insets.
>
> So essentially a single setting for all user-like document settings.
>
> You had convinced me with your "open/closed inset" point that actually LyX 
> records more than I previously thought the current state of user 
> preferences inside files, while my point was that it seems to me that this 
> less LyX's philosophy than e.g. LibreOffice's. I also like the idea that 
> storing the open/closed state of insets may not always be what we want.
>
> But I thought about it more. If the state of insets is lost, then we have 
> to revert to a default state where all the insets are either open or 
> closed. While for some insets I would no mind to lose the state, losing it 
> for all insets looks like a dataloss to me. So we cannot afford to store as 
> user settings things that could cause dataloss.

I did not propose to lose state of all insets, but rather keep it constant
across sessions. If you really really want to change some particular
insets then disable git compatiblity mode, commit it and enable cm again. 

> Also it looks technically challenging to me to store the state of insets as 
> user settings. So I am no longer convinced that not storing open/closed 
> state of insets is feasible and realistic.

No we don't want to store it as user data.

> Still, a single "git compatibility mode" per-document setting would satisfy 
> me equally.

You will have my support if you decide to implement it.

> It comes down to whatever is LyX's philosophy: do we want to store user 
> settings in files? Then let's add a "git mode" per-document setting. Or do 

I would say yes.

Pavel

Re: Lower case mathcal

[Guenter Milde]

On 2015-11-24, Guillaume Munch wrote:
> Le 24/11/2015 19:58, Christopher Menzel a écrit :
>> Dear LyX folk,

>> Quick question — what would it take to get display support for lower
>> case calligraphic letters, which you can get in your rendered PDF via
>> a package like BOONDOX-cal. 

or "urwchancal.sty" http://www.ctan.org/pkg/urwchancal

>> Currently, typing lower case letters >> inside a \mathcal tag in math
>> mode generates a seemingly random selection of symbols.

This matches roughly the output for lower case \mathcal without special
packages. 

> The ideal solution would be to implement support for OTF math fonts in
> LyX's buffer view (essentially http://www.lyx.org/trac/ticket/9014).

...
> Displaying lowercase letters even if not calligraphic
> would be better meanwhile, IMO.

The problem is, that we must ensure that immediate feedback that small
math-script characters are not supported by default.
There was even the idea to prevent users from typing small \mathcal (or
\mathscr) letters.

This calls for a module supporting "urwchancal" or similar packages.
The problem is, that AFAIK, there is no support for math-macros in a
LyX-module. (Correct me if I'm wrong or treat this as feature request.)

Short of this, including a file with math-macros would be the simplest
re-usable workaround.

Günter

Re: Lower case mathcal

[Guenter Milde]

On 2015-11-24, Richard Heck wrote:
> On 11/24/2015 02:58 PM, Christopher Menzel wrote:
>> Dear LyX folk,

>> Quick question — what would it take to get display support for lower case 
>> calligraphic letters, which you can get in your rendered PDF via a package 
>> like BOONDOX-cal. Currently, typing lower case letters inside a \mathcal tag 
>> in math mode generates a seemingly random selection of symbols. Even just 
>> being able to see ordinary lower case letters, even if not calligraphic, 
>> would be preferable. A reasonably good workaround here is to use instant 
>> preview mode, but that's still less than ideal.

>> Just wondering; this is obviously not a major problem but it would be cool 
>> if there was a reasonably easy fix.

> I've noticed this problem, too. I'm not sure why we get the weird
> symbols we do.

Look in lib/symbols: it's using 8-bit TeX fonts with special font encodings.

Günter

Re: My current test failures

[Guenter Milde]

On 2015-11-24, Scott Kostyshak wrote:
> On Tue, Nov 24, 2015 at 07:21:41AM +, Guenter Milde wrote:


>> >> > Below are my current (on 77979d91) test failures:
...
>> This exactly was my critique: your list contains both "straight" and
>> "inverted" tests and it is not clear which of them require now our
>> attention.

> I see. Then I will wait to run the tests again until I get the green
> light that the test results are easy to interpret.

Don't wait. I can now interpret the results and having such "suboptimal"
output helps me to think about possible improvement.


...

>> I understand "non standard" in primary sense to mean "requires
>> non-standard ressources (LaTeX packages and document classes, fonts,
>> ... that are not a requirement for running this test suite".

>> In a wider sense, it is currently used for "not to be expected to
>> succeed on every site that runs this test suite".  This wider
>> definition includes tests that have "arbitrary" result depending on
>> local configuration, OS, TeX distribution, package versions, or the
>> phase of the moon.  A more accurate name for this wider definition
>> would be "random_result".

> Makes sense. As Kornel says, it would be great to put this in
> Development.lyx.

I am working on a categorization and naming -- needs some time and discussion.

>> > By the way, Günter, am I correct that you can now run the tests
>> > yourself?

>> No, I can't.

> Do you want to be able to?

> What is the output of the following commands?

> cmake . && make && ctest -N

After installing cmake, I get:

CMake Error: The source directory "/tmp" does not appear to contain 
CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.


Günter

Re: Win and Mac 2.2.0alpha1 installations independent, right?

[Scott Kostyshak]

On Tue, Nov 24, 2015 at 11:29:58AM +0100, Stephan Witt wrote:

> See this mail:
> 
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg190300.html

+1

Enrico, should we put that patch in for alpha2 and see what happens?

Scott


signature.asc
Description: PGP signature

Re: export doc/fr/Additonal.lyx to pdf4 still fails

[Guenter Milde]

On 2015-11-24, Georg Baum wrote:
> Guenter Milde wrote:

>> Dear Lyxers,

>> thanks to Uwe for removing the non-ASCII character from ERT in
>> doc/fr/Additonal.lyx in 98746f3bda2df7d3/lyxgit.

>> Unfortunately, the export to XeTeX

>>   lyx-svn -e pdf4 Additional.lyx

>> still fails (error log below).

...

>> Error 84 returned from iconv when converting from UCS-4LE to ascii:
>> Ungültiges oder unvollständiges Multi-Byte- oder Wide-Zeichen

> This means that LyX gave invalid unicode to iconv when converting to ASCII. 

Indeed, LyX passes some 8-bit non-ASCII characters.

This is also true if exporting to 8-bit TeX and the inputenc is set to
ASCII - a valid and sensible use-case we should care for:


* characters in Document>Settings>PDF-Info
  (solved for XeTeX), for inputenc==ASCII, there is no easy solution short of
  telling the user to use LICR macros (ä -> \"a etc.).
  
* characters in additions by the Theorems (AMS) module.

   ! Undefined control sequence.
   \theoremname ->\inputencoding 
 {latin9}Th�or�me

It seems the following code in the *.module file uses "language default"
input encoding independent of the setting:

BabelPreamble
  \addto\captions$$lang{\renewcommand{\theoremname}{_(Theorem)}}
EndBabelPreamble




> I think this would be worth investigating, not because export to XeTeX of 
> this document is important, but because this bug may appear in other, more 
> important circumstances as well

It does: inputenc == ASCII 

> French does only need the latin1 subset of 
> unicode, which is covered 100% by lib/unicodesymbols. Therefore, LyX should 
> be able to export to pure ASCII. Even if that is not possible for some 
> reason, it should tell the user (the "uncodable character" warning), and it 
> should never ever send invalid unicode to iconv.

True.

> IMHO it would be a good idea to create a bug report (not demanding working 
> XeTeX export, but for fixing the iconv error).


Günter

Re: My current test failures

[Scott Kostyshak]

On Wed, Nov 25, 2015 at 07:11:50AM +, Guenter Milde wrote:
> On 2015-11-24, Scott Kostyshak wrote:

> > I see. Then I will wait to run the tests again until I get the green
> > light that the test results are easy to interpret.
> 
> Don't wait. I can now interpret the results and having such "suboptimal"
> output helps me to think about possible improvement.

OK good to know.

> >> > By the way, Günter, am I correct that you can now run the tests
> >> > yourself?
> 
> >> No, I can't.
> 
> > Do you want to be able to?
> 
> > What is the output of the following commands?
> 
> > cmake . && make && ctest -N
> 
> After installing cmake, I get:
> 
> CMake Error: The source directory "/tmp" does not appear to contain 
> CMakeLists.txt.
> Specify --help for usage, or press the help button on the CMake GUI.

What happens when you run that command in LyX's source directory? In
LyX's source directory there is a file CMakeLists.txt. That is the file
CMake is looking for.

Scott


signature.asc
Description: PGP signature

Re: simple [patch] support for verbatim*

[Scott Kostyshak]

On Tue, Nov 24, 2015 at 03:13:12PM -0500, Richard Heck wrote:
> On 11/24/2015 03:05 PM, Georg Baum wrote:
> > Of course tex2lyx should either do a perfect roundtrip, or create
> > proper ERT for the new feature. If it does not, then this has to be
> > fixed. However, if there is a bug in tex2lyx that makes it produce
> > invalid output for the new feature, which can also be triggered
> > without the new feature, then I'd see this as completely independent
> > and would even allow the new feature without a tex2lyx fix
> 
> I was thinking that LyX's own support for the feature might mean the bug
> becomes easier to trigger.

Good point.

If we decide on anything it would be nice to add it back into
Development.lyx.

Scott


signature.asc
Description: PGP signature

make distcheck: cannot remove '../../po/lyx.pot'

[Scott Kostyshak]

Can anyone else reproduce this error from the following command?

# make sure no local changes you want to keep in your LyX directory
# first do 'git reset --hard'
# then 'git clean -xdf'
./autogen.sh && ./configure --enable-build-type=pre --disable-nls && make && 
make check && make distcheck && echo "ALL TESTS PASSED"

...

rm: cannot remove ‘../../po/lyx.pot’: Permission denied
Makefile:368: recipe for target 'lyx.pot-update' failed

I wouldn't be surprised if this is something specific to my computer but
thought I would check in just to make sure.

Scott


signature.asc
Description: PGP signature

Re: My current test failures

[Kornel Benko]

Am Mittwoch, 25. November 2015 um 02:28:50, schrieb Scott Kostyshak 

> On Wed, Nov 25, 2015 at 07:11:50AM +, Guenter Milde wrote:
> > On 2015-11-24, Scott Kostyshak wrote:
> 
> > > I see. Then I will wait to run the tests again until I get the green
> > > light that the test results are easy to interpret.
> > 
> > Don't wait. I can now interpret the results and having such "suboptimal"
> > output helps me to think about possible improvement.
> 
> OK good to know.
> 
> > >> > By the way, Günter, am I correct that you can now run the tests
> > >> > yourself?
> > 
> > >> No, I can't.
> > 
> > > Do you want to be able to?
> > 
> > > What is the output of the following commands?
> > 
> > > cmake . && make && ctest -N
> > 
> > After installing cmake, I get:
> > 
> > CMake Error: The source directory "/tmp" does not appear to contain 
> > CMakeLists.txt.
> > Specify --help for usage, or press the help button on the CMake GUI.
> 
> What happens when you run that command in LyX's source directory? In
> LyX's source directory there is a file CMakeLists.txt. That is the file
> CMake is looking for.

If you use 'cmake .', that means you have to be at the top of lyx source 
directory.
But I strongly discourage such  call.
I tried to not mess the source directory even in the case one really does use 
'.', but
there are always left traces of cmake created files in the source.
Therefore before using own build directory one would have to clean the source 
first.

So select/create a directory you want the build in, chdir to it, and call
'cmake '

> Scott

Kornel

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

alpha2

[Scott Kostyshak]

Thanks to Georg for clearing up the regex situation.

It would be nice to make an attempt at a fix for the Windows icon issue
that Andrew has reported. Any opinions on putting this patch in alpha2?

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg190300.html

Scott


signature.asc
Description: PGP signature

Re: My current test failures

[Kornel Benko]

Am Dienstag, 24. November 2015 um 15:48:36, schrieb Guenter Milde 

> On 2015-11-24, Kornel Benko wrote:
> > Am Dienstag, 24. November 2015 um 11:52:19, schrieb Guenter Milde 
> > 
> >> On 2015-11-24, Kornel Benko wrote:
> 
> 
> >> >> I am in the process of devicing a new categorization (or naming for the
> >> >> categories), for what we currently call "nonstandard", I have:
> 
> >> >> + unreliable# export may work or fail (we don't know for sure)
> 
> >> >>   - nonstandard # requires packages or other ressources that are not on 
> >> >> CTAN
> >> >> # (some developers may have them installed)
> 
> >> >>   - erratic # depending on local configuration, OS, TeX 
> >> >> distribution,
> >> >>   # package versions, or the phase of the moon.
> 
> 
> >> > The problem here is that we would need some handling to distinguish the
> >> > cases. ATM it is done by using different files ('*Tests'). The files
> >> > itself contain comments (starting with '#') and regexes. I try to
> >> > implement some sort of sublabels though.
> 
> >> As a start, you could rename "nonstandard" to "unreliable" and
> >> place sublabels just as "header comment", e.g.
> 
> >> file unreliableTests:
> 
> >> # nonstandard
> >> # ===
> 
> > This is not so easy, because at the time of checking I see only lines
> > without comments
> 
> It was just an idea for a stop-gap measure.
> 
> > What about
> > 'Sublabel: nonstandard'
> > ?
> 
> I don't know how you want to implemement it, but if the output contains then
> lines like
> 
>  UNRELIABLE.NON_STANDARD.export/templates/ectaart_dvi3_systemF
>
>  UNRELIABLE.ERRATIC.export/examples/seminar_dvi
> 
> or
> 
>  NON_STANDARD.UNRELIABLE.export/templates/ectaart_dvi3_systemF
> 
>  ERRATIC.UNRELIABLE.export/examples/seminar_dvi
> 
> this is fine.

It is there. Names are
UNRELIABLE.SUBLABEL_export/templates/...
'SUBLABEL' is uppercase of the used sublabel.

Now one can test e.g.
'ctest 'L erratic'
to test only erratic tests defined in unreliableTests.
Unfortunately nothing prevent us ATM using same labels in .*Tests files.

> Günter

Kornel

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

Re: simple [patch] support for verbatim*

[Jean-Marc Lasgouttes]

Le 24/11/2015 18:57, Richard Heck a écrit :

I was mostly thinking that (a) if we're going to add this for 2.2, the
tex2lyx part should also be done---the rule you quoted applies to
mid-cycle commits and doesn't say anything about what should be done for
a major release---and (b) that the test file I attached (a minimal
modification of the existing one) gets totally mangled. The \verbatim*
command isn't even output properly as ERT.

This actually seems to be an existing bug:


I will try to do the tex2lyx part ASAP. The bug that you see is probably 
because there is some ugly stuff in the environment. I am not sure there 
is something to fix besides adding support for verbatim*.


JMarc

Re: My current test failures

[Scott Kostyshak]

On Tue, Nov 24, 2015 at 07:21:41AM +, Guenter Milde wrote:
> On 2015-11-24, Scott Kostyshak wrote:
> > On Mon, Nov 23, 2015 at 10:40:11PM +, Guenter Milde wrote:
> >> On 2015-11-21, Scott Kostyshak wrote:
> 
> >> > Below are my current (on 77979d91) test failures:
> 
> >> Thank you for the list. However, I would rather call this a list of
> >> "export failures". 
> 
> >> Only a small subset of them are "test failures":
> >> the others are either
> >> a) passing the test if export fails (inverted), or
> >> b) passing the test in any case or not tested (nonstandard, ignored)
> 
> > I've read this a few times and don't understand. The reason why I don't
> > like the phrase "export failure" is because we don't know if an export
> > failure is expected or not. 
> 
> This exactly was my critique: your list contains both "straight" and
> "inverted" tests and it is not clear which of them require now our attention.

I see. Then I will wait to run the tests again until I get the green
light that the test results are easy to interpret.

> > Once the tests are stable, however, we should expect all tests to
> > pass.
> 
> 
> I understand "non standard" in primary sense to mean "requires
> non-standard ressources (LaTeX packages and document classes, fonts,
> ... that are not a requirement for running this test suite".
> 
> In a wider sense, it is currently used for "not to be expected to
> succeed on every site that runs this test suite".  This wider
> definition includes tests that have "arbitrary" result depending on
> local configuration, OS, TeX distribution, package versions, or the
> phase of the moon.  A more accurate name for this wider definition
> would be "random_result".

Makes sense. As Kornel says, it would be great to put this in
Development.lyx.

> > By the way, Günter, am I correct that you can now run the tests
> > yourself?
> 
> No, I can't.

Do you want to be able to?

What is the output of the following commands?

cmake . && make && ctest -N

Once that works, then you should instead use a separate build directory.

Scott


signature.asc
Description: PGP signature

Re: export doc/fr/Additonal.lyx to pdf4 still fails

[Scott Kostyshak]

On Tue, Nov 24, 2015 at 10:49:38AM +, Guenter Milde wrote:
> Dear Lyxers,
> 
> thanks to Uwe for removing the non-ASCII character from ERT in 
> doc/fr/Additonal.lyx in 98746f3bda2df7d3/lyxgit.
> 
> Unfortunately, the export to XeTeX
> 
>   lyx-svn -e pdf4 Additional.lyx 
>   
> still fails (error log below).
> 
> What shall we do?
> 
> * Explore and try to find a reason,
> 
> * Leave as "wontfix" 
> 
> Noone needs to export this document with XeTeX so this may be wasted effort.

I would say do not spend the time (it sounds like you don't think it is
worth it) but when we invert it please put a comment explaining that we
don't know why it fails and if someone wants to spend the time they
might be able to fix it.

Scott


signature.asc
Description: PGP signature

Re: simple [patch] support for verbatim*

[Richard Heck]

On 11/23/2015 10:33 PM, Scott Kostyshak wrote:
> On Mon, Nov 23, 2015 at 09:10:23PM -0500, Richard Heck wrote:
>
>> Uwe, please test that this new patch does what you want it to do. I've
>> tested it, but only minimally.
>>
>> Another issue is that \verbatim* is not presently handled properly by
>> tex2lyx. If we are going to add verbatim* support for 2.2, then it seems
>> to me that we should also have tex2lyx support. What's worse is that
>> tex2lyx makes a total mess of that other file I've attached.
> From what I understand of the steps in Development.lyx, this is not
> required. Should we change the rules? Currently it states:
>
> 7. If you did not implement full tex2lyx support of the new
> feature, add a line to src/tex2lyx/TODO.txt describing the missing
> bits. Note that it is perfectly fine if you do not add full
> tex2lyx support for a new feature: The updating recommendation
> above is only issued for the syntax of the produced .lyx file. It
> is no problem if some features supported by LyX are still output
> as ERT by tex2lyx, since the problems in the past that resulted in
> the update recommendation were related to mixed version syntax,
> not ERT.
>
> So why can't Uwe just add a line to src/tex2lyx/TODO.txt as
> detailed above?

I was mostly thinking that (a) if we're going to add this for 2.2, the
tex2lyx part should also be done---the rule you quoted applies to
mid-cycle commits and doesn't say anything about what should be done for
a major release---and (b) that the test file I attached (a minimal
modification of the existing one) gets totally mangled. The \verbatim*
command isn't even output properly as ERT.

This actually seems to be an existing bug:

Creating file /music/cvs/lyx/lyx-devel/src/tex2lyx/test/verbatim.lyx
Line ~3:  parse error: found 'end' unexpectedly

Tokens: \documentclass [{,1]article[},2][1\n,5]
\begin [{,1]document[},2][1\n,5]
\begin [{,1]verbatim[},2][ ,12][\,12]verbatim[ ,12][$,12]src[ ,12]set[
,12]packetSize[_,12][ ,12][1,12][0,12][0,12][0,12][0,12][0,12][
,12][\,12]end[{,12]verbatim[},12][1\n,5]
\begin [{,1]verbatim[*,12][},2] \verbatim [*,12] [$,3]src set
packetSize[_,8] [1,12][0,12][0,12][0,12][0,12][0,12] \end  pos: 133
Line ~4:  parse error: found 'end' unexpectedly

Tokens: \documentclass [{,1]article[},2][1\n,5]
\begin [{,1]document[},2][1\n,5]
\begin [{,1]verbatim[},2][ ,12][\,12]verbatim[ ,12][$,12]src[ ,12]set[
,12]packetSize[_,12][ ,12][1,12][0,12][0,12][0,12][0,12][0,12][
,12][\,12]end[{,12]verbatim[},12][1\n,5]
\begin [{,1]verbatim[*,12][},2] \verbatim [*,12] [$,3]src set
packetSize[_,8] [1,12][0,12][0,12][0,12][0,12][0,12] \end
[{,1]verbatim[*,12][},2][1\n,5]
\end  pos: 146

Richard

Re: [PATCH] Re: Regression in lyx2lyx box alignment

[Uwe Stöhr]

  Original Message  
From: Jean-Marc Lasgouttes
Sent: Dienstag, 24. November 2015 09:33

> As I already explained in the relevant thread, there are already cases 
where we do what you want: table cells and floats. It would be trivial 
to extend this so that alignment is done like that also for makebox (we 
do not want to change minipage/parbox, do we?).

Makebox works already as it should in my opinion. For minipage and parbox it 
must be changed! I don't see what you mran with like for table cells. Their 
alignment ist not set via \raggedleft etc. but thus must be used here. Or what 
LaTex construct di you have in mind to set the alignment in a parbox?

> As for the difference between parbox 
and makebox, do the manual explain LR mode? This is the key difference IMO.

I will have a look. 

Thanks and regards Uwe

Re: 'make check' still fails

[Georg Baum]

Scott Kostyshak wrote:

> On Sun, Nov 22, 2015 at 06:40:45PM +, Guillaume Munch wrote:
>> Le 22/11/2015 17:38, Georg Baum a écrit :
>> >It is now also clear that the MSVC workaround is not needed, so I
>> >deleted it. Is the attached patch OK to go in?
>> 
>> Looks good (I trust that the small details are ok). I have the same
>> understanding. Isn't the "FIXME: Unicode" trivial to fix btw?
> 
> I would say commit then.

Done. To my knowledge there are no known problems with std::regex anymore.


Georg

Re: Win and Mac 2.2.0alpha1 installations independent, right?

[Jean-Marc Lasgouttes]

Le 24/11/2015 02:03, Uwe Stöhr a écrit :

Am 24.11.2015 um 01:56 schrieb Scott Kostyshak:


The svgz icons aren't displaying for me in 2.2 and evidently...


Interesting. This is bad news.


I thought they are only shown with Qt 5.5 but I compiled alpha1 with Qt
4.8.


And did you include the qtsvg dll (or whatever it is called) in the 
installer? It may be that it works for you because you have it acessible 
elsewhere.


JMarc

Re: [PATCH] Fix offset error in computation of hfills

[Jean-Marc Lasgouttes]

Le 24/11/2015 01:48, Uwe Stöhr a écrit :

Am 23.11.2015 um 18:05 schrieb Jean-Marc Lasgouttes:


Can I commit this first patch?


The patch looks reasonable but why is this change necessary?:

-dim = Dimension(10, 10, 10);
+dim = Dimension(5, 10, 10);

Maybe the reason for the values should be documented in a comment.


The two last 10 are ascent and descent. For the first one (the width), 
the old code read:


if (pm.hfillExpansion(row, cit->pos))
cit->dim.wid = int(cit->pos >= body_pos ?
   max(hfill, 5.0) : row.label_hfill);
else
cit->dim.wid = 5;

So, as you can see the width of a non-expanded hfill is set to 5. So the 
initial value of 10 is not used. It is better to initialize it properly 
from the start.


As for the reason for the values, I don't know. I'd say they are 
arbitrary :)


JMarc

Re: [PATCH] Re: Regression in lyx2lyx box alignment

[Jean-Marc Lasgouttes]

Le 24/11/2015 01:21, Uwe Stöhr a écrit :

Yes. Sorry, I meant the extra space. And this was the reason why I once
added the possibility to set the vertical alignment in boxes - for this
application there must not be extra space as I demonstrated.
As we now have the infrastructure to display the alignment I would like
to re-implement to set the alignment for all boxes via \raggedright etc.
Or what stands in your opinion against this?


As I already explained in the relevant thread, there are already cases 
where we do what you want: table cells and floats. It would be trivial 
to extend this so that alignment is done like that also for makebox (we 
do not want to change minipage/parbox, do we?).


I have to admit that this business of arbitrarily changing how alignment 
should be done makes me a bit nervous. But we can do that.



To be fair, that are many things that are not obvious in the box dialog.
First: why would one choose parbox, minipage or makebox. This choice
assumes that one knows how LaTeX boxes work. In this case, one also
knows about alignment parameters, right?


Hmm, it is explained in the docs that a minipage is like a page and that
a parbox is like a small minipage while a makebox cannot have several
paragraphs. I think that we can assume that these differences can be
understood (OK the difference between parbox and minipage is quite
small). So in case the user understands the difference it is not clear
why he cannot set a horizontal alignment for the box content because
this is independent from if several paragraphs are allowed or not.


I meant without reading the docs. As for the difference between parbox 
and makebox, do the manual explain LR mode? This is the key difference IMO.


JMarc

Re: [PATCH] Fix offset error in computation of hfills

[Jean-Marc Lasgouttes]

Le 24/11/2015 00:55, Guillaume Munch a écrit :

A simple argument for going further and getting rid of
ParagraphMetrics::hfillExpansion (which I understand is causing the
remaining problem) is that LyX's row breaks are different from LaTeX's
anyway, as shown in Example 3 (or whenever there is a wide inset in the
paragraph).


I do not really understand myself when hfills get discarded. As I 
understand it, hspace can be discarded too in some cases. I have first 
to have a description of the algorithm to be able to proceed.


Note that we remove spaces via DEPM at the beginning of paragraphs just 
for this reason. Does this mean that we should do the same for hfills 
and hspaces? This strikes me as a bit exagerated, but at the same time 
it is just spaces.



I confirm that Example 1 is solved in my test and it did not crash on my
hands. Probably only you can judge the details of the code, but it looks
simple enough for committing.


Thanks.

JMarc

Re: Win and Mac 2.2.0alpha1 installations independent, right?

[Jean-Marc Lasgouttes]

Le 24/11/2015 04:02, Andrew Parsloe a écrit :

Removing the svgz does allow the png icons to display.


Andrew, can you have a look where LyX 2.2 is installed and look whether 
there is a dll like qtsvg.dll? It is known that not installing (or 
linking against) this dll will cause the problem you describe, in linux 
at least.


JMarc

Re: My current test failures

[Kornel Benko]

Am Dienstag, 24. November 2015 um 07:21:41, schrieb Guenter Milde 

> On 2015-11-24, Scott Kostyshak wrote:
> > On Mon, Nov 23, 2015 at 10:40:11PM +, Guenter Milde wrote:
> >> On 2015-11-21, Scott Kostyshak wrote:

...
 
> >> Here, IEEEtran-Conference.lyx compiles with both, pdflatex and lualatex
> >> while IEEEtran-TransMag.lyx fails with both, due to undefined commands
> >> (version clash?).
> 
> > Good to know. This might have to do with my outdated TL 2015. I'll see
> > if this changes when updating.
> 
> >> > 3900:NON_STANDARD.export/templates/IUCr-article_pdf4_systemF
> 
> >> > 4033:export/templates/ectaart_dvi3_texF
> >> > 4034:export/templates/ectaart_dvi3_systemF
> >> > 4040:export/templates/ectaart_pdf5_texF
> >> > 4041:export/templates/ectaart_pdf5_systemF
> 
> >> Non standard, see http://wiki.lyx.org/Examples/Econometrica

They already are in nonstandard.

> > I still don't understand what NON_STANDARD means (did we define it
> > somewhere in Development.lyx?) but indeed it is not in TeX Live so in
> > that sense I agree.
> 
> I understand "non standard" in primary sense to mean
> "requires non-standard ressources (LaTeX packages and document classes,
> fonts, ... that are not a requirement for running this test suite".
> 
> In a wider sense, it is currently used for "not to be expected to succeed
> on every site that runs this test suite".
>   This wider definition includes tests that have "arbitrary" result depending
> on local configuration, OS, TeX distribution, package versions, or the phase
> of the moon.
>   A more accurate name for this wider definition would be "random_result".

Nice wording. I'd like to add it to Development.lyx

> > By the way, Günter, am I correct that you can now run the tests
> > yourself?
> 
> No, I can't.

That is a pity.

> Günter

Kornel

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

Re: Win and Mac 2.2.0alpha1 installations independent, right?

[Stephan Witt]

Am 24.11.2015 um 11:10 schrieb Andrew Parsloe :

> On 24/11/2015 9:54 p.m., Jean-Marc Lasgouttes wrote:
>> Le 24/11/2015 04:02, Andrew Parsloe a écrit :
>>> Removing the svgz does allow the png icons to display.
>> 
>> Andrew, can you have a look where LyX 2.2 is installed and look whether 
>> there is a dll like qtsvg.dll? It is known that not installing (or linking 
>> against) this dll will cause the problem you describe, in linux at least.
>> 
>> JMarc
> I've attached the contents of C:/Program Files (x86)/LyX 2.2/bin. I can see 
> QtSvg.dll and qsvg.dll.
> 
> Andrew
> 


See this mail:

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg190300.html

Re: Win and Mac 2.2.0alpha1 installations independent, right?

[Andrew Parsloe]

On 24/11/2015 9:54 p.m., Jean-Marc Lasgouttes wrote:

Le 24/11/2015 04:02, Andrew Parsloe a écrit :

Removing the svgz does allow the png icons to display.


Andrew, can you have a look where LyX 2.2 is installed and look 
whether there is a dll like qtsvg.dll? It is known that not installing 
(or linking against) this dll will cause the problem you describe, in 
linux at least.


JMarc
I've attached the contents of C:/Program Files (x86)/LyX 2.2/bin. I can 
see QtSvg.dll and qsvg.dll.


Andrew


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: My current test failures

[Guenter Milde]

On 2015-11-24, Kornel Benko wrote:
> Am Dienstag, 24. November 2015 um 07:21:41, schrieb Guenter Milde 
> 

...

>> >> > 3900:NON_STANDARD.export/templates/IUCr-article_pdf4_systemF

>> >> > 4033:export/templates/ectaart_dvi3_texF
>> >> > 4034:export/templates/ectaart_dvi3_systemF
>> >> > 4040:export/templates/ectaart_pdf5_texF
>> >> > 4041:export/templates/ectaart_pdf5_systemF

>> >> Non standard, see http://wiki.lyx.org/Examples/Econometrica

> They already are in nonstandard.

>> > I still don't understand what NON_STANDARD means
...
> Nice wording. I'd like to add it to Development.lyx

I am in the process of devicing a new categorization (or naming for the
categories), for what we currently call "nonstandard", I have:

  + unreliable# export may work or fail (we don't know for sure)

- nonstandard # requires packages or other ressources that are not on 
CTAN
  # (some developers may have them installed)
  
- erratic # depending on local configuration, OS, TeX distribution,
  # package versions, or the phase of the moon.


Günter

Re: [LyX/master] Document the export tests and other tests

[Guenter Milde]

On 2015-11-21, Kornel Benko wrote:
> Am Samstag, 21. November 2015 um 22:21:59, schrieb Guenter Milde 
> 

...

>> >> >> >> ATM, the line reads
>> >> >> >> 'foreach(libsubfolderx lib/doc lib/examples lib/templates)'

>> The idea was to put the test code not under lib (reserved for files that
>> should ship with any LyX installation), but in a dedicated test directory in
>> the reporsitory root. I.e. text is not a "libsubfolder" but a
>> "libparallelfolder" and the cmake test machinery should care for this.


> This is all understood.
> Therefore the foreach() would read
>   'foreach(libsubfolderx lib/doc lib/examples lib/templates 
> autotests/something)'

I was misled by first argument "libsubfolderx" - it seams this is no longer
appropriately named but does the right thing...

Günter

Re: My current test failures

[Guenter Milde]

On 2015-11-24, Kornel Benko wrote:


>> I am in the process of devicing a new categorization (or naming for the
>> categories), for what we currently call "nonstandard", I have:

>>   + unreliable# export may work or fail (we don't know for sure)

>> - nonstandard # requires packages or other ressources that are not 
>> on CTAN
>>   # (some developers may have them installed)

>> - erratic # depending on local configuration, OS, TeX 
>> distribution,
>># package versions, or the phase of the moon.


> The problem here is that we would need some handling to distinguish the
> cases. ATM it is done by using different files ('*Tests'). The files
> itself contain comments (starting with '#') and regexes. I try to
> implement some sort of sublabels though.

As a start, you could rename "nonstandard" to "unreliable" and
place sublabels just as "header comment", e.g.

file unreliableTests:

# nonstandard
# ===
#
# Tests using non-standard tex class or package

export/templates/IUCr-article_(dvi|pdf).*
export/templates/es_beamer-conference-ornate-20min_pdf4_texF
export/templates/kluwer_pdf[45]_systemF
export/examples/modernCV_pdf4_(tex|system)F
export/templates/ectaart_(dvi3|pdf5)_(tex|system)F


# erratic
# ===
#
# Tests depending on local configuration, OS, TeX distribution,
# package versions, or the phase of the moon.

export/examples/(|fr/)seminar_(dvi|pdf|pdf[23]|pdf4_texF|pdf5_systemF)





BTW: I am not sure this belongs to "unreliable":
# 1.) missing farsi package with lfeenc.def
# 2.) LuaTeX does not support Farsi yet. See:
# 
https://github.com/reutenauer/polyglossia/commit/ccb0e9e2c6411170ad779b05ff5076f1193cc323
export/examples/fa/splash_(dvi|pdf|pdf[23]|(dvi3|pdf4|pdf5)_(texF|systemF))

Re: My current test failures

[Kornel Benko]

Am Dienstag, 24. November 2015 um 10:52:55, schrieb Guenter Milde 

> On 2015-11-24, Kornel Benko wrote:
> > Am Dienstag, 24. November 2015 um 07:21:41, schrieb Guenter Milde 
> > 
> 
> ...
> 
> >> >> > 3900:NON_STANDARD.export/templates/IUCr-article_pdf4_systemF
> 
> >> >> > 4033:export/templates/ectaart_dvi3_texF
> >> >> > 4034:export/templates/ectaart_dvi3_systemF
> >> >> > 4040:export/templates/ectaart_pdf5_texF
> >> >> > 4041:export/templates/ectaart_pdf5_systemF
> 
> >> >> Non standard, see http://wiki.lyx.org/Examples/Econometrica
> 
> > They already are in nonstandard.
> 
> >> > I still don't understand what NON_STANDARD means
> ...
> > Nice wording. I'd like to add it to Development.lyx
> 
> I am in the process of devicing a new categorization (or naming for the
> categories), for what we currently call "nonstandard", I have:
> 
>   + unreliable# export may work or fail (we don't know for sure)
> 
> - nonstandard # requires packages or other ressources that are not on 
> CTAN
>   # (some developers may have them installed)
> 
> - erratic # depending on local configuration, OS, TeX 
> distribution,
> # package versions, or the phase of the moon.
> 

The problem here is that we would need some handling to distinguish the cases. 
ATM it is done by
using different files ('*Tests').
The files itself contain comments (starting with '#') and regexes.
I try to implement some sort of sublabels though.

> Günter

Kornel


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

Re: My current test failures

[Guenter Milde]

On 2015-11-24, Kornel Benko wrote:
> Am Dienstag, 24. November 2015 um 11:52:19, schrieb Guenter Milde 
> 
>> On 2015-11-24, Kornel Benko wrote:


>> >> I am in the process of devicing a new categorization (or naming for the
>> >> categories), for what we currently call "nonstandard", I have:

>> >> + unreliable# export may work or fail (we don't know for sure)

>> >>   - nonstandard # requires packages or other ressources that are not on 
>> >> CTAN
>> >> # (some developers may have them installed)

>> >>   - erratic # depending on local configuration, OS, TeX distribution,
>> >> # package versions, or the phase of the moon.


>> > The problem here is that we would need some handling to distinguish the
>> > cases. ATM it is done by using different files ('*Tests'). The files
>> > itself contain comments (starting with '#') and regexes. I try to
>> > implement some sort of sublabels though.

>> As a start, you could rename "nonstandard" to "unreliable" and
>> place sublabels just as "header comment", e.g.

>> file unreliableTests:

>> # nonstandard
>> # ===

> This is not so easy, because at the time of checking I see only lines
> without comments

It was just an idea for a stop-gap measure.

> What about
>   'Sublabel: nonstandard'
> ?

I don't know how you want to implemement it, but if the output contains then
lines like

 UNRELIABLE.NON_STANDARD.export/templates/ectaart_dvi3_systemF

 UNRELIABLE.ERRATIC.export/examples/seminar_dvi

or

 NON_STANDARD.UNRELIABLE.export/templates/ectaart_dvi3_systemF

 ERRATIC.UNRELIABLE.export/examples/seminar_dvi

this is fine.

Günter

Re: My current test failures

[Kornel Benko]

Am Dienstag, 24. November 2015 um 11:52:19, schrieb Guenter Milde 

> On 2015-11-24, Kornel Benko wrote:
> 
> 
> >> I am in the process of devicing a new categorization (or naming for the
> >> categories), for what we currently call "nonstandard", I have:
> 
> >>   + unreliable# export may work or fail (we don't know for sure)
> 
> >> - nonstandard # requires packages or other ressources that are not 
> >> on CTAN
> >>   # (some developers may have them installed)
> 
> >> - erratic # depending on local configuration, OS, TeX 
> >> distribution,
> >>  # package versions, or the phase of the moon.
> 
> 
> > The problem here is that we would need some handling to distinguish the
> > cases. ATM it is done by using different files ('*Tests'). The files
> > itself contain comments (starting with '#') and regexes. I try to
> > implement some sort of sublabels though.
> 
> As a start, you could rename "nonstandard" to "unreliable" and
> place sublabels just as "header comment", e.g.
> 
> file unreliableTests:
> 
> # nonstandard
> # ===

This is not so easy, because at the time of checking I see only lines without 
comments
What about
'Sublabel: nonstandard'
?

> # Tests using non-standard tex class or package
> 
> export/templates/IUCr-article_(dvi|pdf).*
> export/templates/es_beamer-conference-ornate-20min_pdf4_texF
> export/templates/kluwer_pdf[45]_systemF
> export/examples/modernCV_pdf4_(tex|system)F
> export/templates/ectaart_(dvi3|pdf5)_(tex|system)F
> 
> 
> # erratic
> # ===
> #
> # Tests depending on local configuration, OS, TeX distribution,
> # package versions, or the phase of the moon.
> 
> export/examples/(|fr/)seminar_(dvi|pdf|pdf[23]|pdf4_texF|pdf5_systemF)
> 
> 
> 
> 
> 
> BTW: I am not sure this belongs to "unreliable":
> # 1.) missing farsi package with lfeenc.def
> # 2.) LuaTeX does not support Farsi yet. See:
> # 
> https://github.com/reutenauer/polyglossia/commit/ccb0e9e2c6411170ad779b05ff5076f1193cc323
> export/examples/fa/splash_(dvi|pdf|pdf[23]|(dvi3|pdf4|pdf5)_(texF|systemF))

This is a TODO then.

Kornel

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