Re: thoughts about LyX's future and proposals
Thanks Helge. You made your point and I fully concur. It is as simple as that: Different tasks need different tools. Who wants to deny that fact? Michael Am 30.07.2018 um 16:13 schrieb Helge Hafting: Den 10. juli 2018 00:19, skrev Uwe Stöhr: [...] * compatibility with other file formats: a major task is to collaborate with others. My solution to this is: use LyX when the others writes LyX or LaTeX. Otherwise, use libreoffice. (word is not an option - I don't use the required windows and I don't pay for sw where good free alternatives exists.) I don't think it is a problem to have more than one word processor. Hence, I don't need LyX to do "everything". I use it for writing, which it does very well. Certainly much better than the alternatives I have seen. I can use libreoffice when someone wants comments on their docx. (And others can use LyX, if they want to co-author with me.) The required sw is free either way, and disk space is cheap enough these days. I don't see why LyX would be a no-go just because "it won't open your old word documents." Word users already have word for that. Just make it clear that this is the case, LyX is for writing new documents (and working on old LyX documents, of course.) One-off conversion can usually be done by copy+paste. My impression is that file format converters are very hard, because the underlying file formats are so different. Word positions stuff on a page - LyX collects your sentences, keeps track of what it all is (text, heading, abstract etc) and do page breaking just-in-time when printing. Before a converter can be written (by volunteer or a funded programmer) we need to know what such a conversion should do: * Create a converted document that renders the same way on the other platform? I don't think this is realistic. If we go for the same line/page breaking, then the converted document will be full of positioning commands, and certainly not something that can be edited in a meaningful way. * A "reasonable" conversion in that headings become headings, plain text becomes plain text - and all supportable features survive conversion? The first problem with this, is that people *will* complain when something looks different. Even if still looks good. A subsection might get on another page, making it hard to phone up a co-author "to fix the spelling error on page 13, at the end of the second line". Another problem is that many word documents are created in a very bad way. There are forced line breaks, forced page breaks and similar all over. (A "good" word document is one that looks nice, and where you can change the text size, the page size and the margins - and then it still looks good without you having to change anything. Such a document may not be hard to convert to LyX.) A document that has some manual line breaks, usually breaks badly if you increase the font size or make the lines a little shorter. Such a document will also be hard to convert to LyX in a meaningful way. What to do about a manual page break? Word users uses them to avoid getting a heading at the end of page - as word doesn't always do that automatically. But they also use them mistakenly, where word is capable of breaking automatically. Upon conversion to LyX, the line breaking will be different, and also the page breaking. LyX still support forced breaks, but should we take them all, or none, or some? Third problem: too many features that doesn't exist in both LyX and word, which breaks conversions of any documents using them. I am not opposed to converters, but even specifying one seems hard. If you can solve that problem, then a converter might be possible to write. [...] I could add some more things. But this is not my point. I see that most LyX developers only code for their pleasure not for the things the potential customers need the most. That might have something to do with not having any actual customers. (paying customers, that is.) Volunteers generally do what they want, and rarely care about 'market share'. I want enough 'market share' that LyX keeps being developed - but we are there already. You may want to look into Pavel's idea about funding features for those willing to pay. I don't want to blame anybody but I want to make clear that we all need to improve our sights to the real world. There is a good reason why more than 90 % of PC users use Windows. I am not sure there are any good reasons for those 90%, other than marketing & inertia. It is not as if windows actually have advantages. (Use windows because you always used windows - even if the new version is almost as different from the old as linux is). Incidentally, this inertia also means lots of people won't switch word processor - even if all shortcomings in LyX were fixed. For example I also made my step out of the Windows world to understand how it is under Linux. I found out that it does change the view on
Re: Windows Texlive and/or Miktex
On 09.06.2018 12:10, Jürgen Spitzmüller wrote: Am Samstag, den 09.06.2018, 11:21 +0200 schrieb Michael Berger: Hello, I use Mageia 6 (Texlive) and reading linguistic papers produced with LyX in Windows (Miktex) poses a problem. Is there a chance for Linux users to one day read and PDF view documents produced in Windows/Miktex and vice versa? Your problem has nothing to do with Linux vs. MikTeX, but most probably with different package versions in the respective LaTeX installations. In any case, this is not something that is in our (LyX's) hands. In order to trace the problem, add listfiles to the preamble, check and compare the versions of the used packages that are output at the end of the LaTeX log (particularly in your case, I suspect, covington). Jürgen Michael Hallo Jürgen, I will attend to what you are suggesting. Meanwhile I understand that this indeed has nothing to do with Linux vs. MikTex - so my assumption was basically wrong and that is first of all important to realize. Best and thanks, Michael
Re: Windows Texlive and/or Miktex
On 09.06.2018 11:54, Kornel Benko wrote: Am Samstag, 9. Juni 2018 11:21:46 CEST schrieb Michael Berger : > Hello, > > I use Mageia 6 (Texlive) and reading linguistic papers produced with LyX > in Windows (Miktex) poses a problem. It should work. > Is there a chance for Linux users to one day read and PDF view documents > produced in Windows/Miktex and vice versa? > > Michael > What is the problem? Kornel Thanks Kornel, I am using Mageia 6 and cannot convert my son's linguistic papers to PDF produced under Windows on a computer provided by his Leipzig University. 'Show output anyway' is grayed out. So, your question implies that this ought to work. But if so, what am I possibly doing wrong? I am totally confused by now! Michael
Windows Texlive and/or Miktex
Hello, I use Mageia 6 (Texlive) and reading linguistic papers produced with LyX in Windows (Miktex) poses a problem. Is there a chance for Linux users to one day read and PDF view documents produced in Windows/Miktex and vice versa? Michael
Windows Texlve and/or Miktex
Hi all, very sorry for the garbage from just now! Mea maxima culpa!! :-( Michael
Windows Texlive and/or Miktex
Hi, I am an ordinary user engaged in exchanging linguistic papers with some people using Windows and others using Linux Distributions. Will there ever be a situation that allowes the users LyX user to compiles there to come - a single Windows installation that allows to switch between Miketex or Texlive or do we need two different Windows installations, one for Miktex and another one for Texlive?
KMM 5.0.0
Hello Thomas, I upgraded KMM to version 5.0.0 and I am back in business after having to do some minor corrections re foreign currency exchange rates. My base currency is the EURO. Currencies like the Swiss Franc and others showed correct exchange rates that did not need any adjustment. But the exchange rates of currencies with an extrem splay like the € to IDR (1€ ~ 16 500 IDR) returned large crazy figures that made no sense at all. But then it was easy to make the necessary corrections in KMM's Price Editor. I increased the default precision setting to eight digits, e.g. 1 IDR equals 0,6001 €. The Price Editor is now back to presenting the online quotes as before - special thanks for this great add-in feature! Should I come across some other imperfections I will report them to you (but so far it doesn't look like). I am using Mageia 6 Thanks again for the great program and best regards, Michael
Re: Character Style vs. Text Properties
On 07.05.2018 18:27, Richard Kimberly Heck wrote: On 05/07/2018 08:56 AM, Jürgen Spitzmüller wrote: Dear all After having reworked the dialog and the manual, I propose to rename everything related to the character dialog "Text Properties" (instead of "Text Style"). The reason is that almost everyhing set there (except for noun and emph, the only real text styles proper) is static (formal) markup. I propose to reserve "Style" for something that is a defined entity, something whose properties can be changed at a central place (i.e., semantic markup). This also clarifies the UI, where you now have "Character Styles" (semantic markup) and "Text Style" (formal markup) next to each other (I'd even prefer "Text Style" over "Character Style", since the semantic markup does not only change characters, but the appearance of text passages [underlining is not part of a character, for instance, nor is enquoting]). That all seems sensible to me. Riki Though I am just an ordinary user and have no idea how you could ever achieve all these improvements, but all you are proposing here makes a lot of sense to me. Thanks to you and your colleagues for your continuous efforts! Michael
no PDF when using classicthesis-LyX-v4.2_biblatex_biber / ..._biblatex_bibtex8
Dear Lyxers,
my Linguistic Thesis at first written in classicthesis-LyX-v4.1 converts
to PDF in both versions of classicthesis-LyX-v4.2 but only after having
removed all letters used to typeset African Languages as shown in Table
7 of the Comprehensive LaTeX Symbol List by Scott Pakin.
While my Thesis successfully handles the languages Turkish, Indonesian,
Serbo-Croatian and Tamil it fails compilation to PDF as long as any of
the two African languages Asante-Twi and/or Limbum remains present.
This was tried with classicthesis-LyX-v4.2 and using two different
systems namely openSUSE Leap 14.2 and Mageia 6 - both do show the same
behavior.
The package fc is in place with all its elements (fclfont.sty,
fcuse.sty, t4cmr.fd, t4cmss.fd, fclfont.sty_old, t4cmtt.fd, t4enc.def,
t4fcr.fd and t4phonet.sty).
\usepackage[T4]{fontenc} is present in the preamble.
Using other document classes e. g. Koma-Script do compile without
problems as long as \usepackage[T4]{fontenc} is part of the preamble.
Am I doing something wrong or could it be that classicthesis-LyX-v4.2 is
not yet fit?
Any help or comment is highly appreciated.
Thanks and cheers!
Michael
Re: short report from LyX under Linux
Am 24.07.2017 um 10:30 schrieb "Uwe Stöhr":
back to the UserGuide, perhaps what we could actually do is, to simplify
the UserGuide so that it can compile without the need for installing additional
packages besides a minimal latex installation
The point is that almost nothing works out of the box. Not simple documents,
not the tutorial. Because only texlive-bin package is installed together with
LyX. I will report to the packagers that they should add more texlive packages
to the install dependencies.
I would recommend an established distribution, such as openSuse.
I haven't heard of this distro yet. I see now that Manjaro is on place 3 on
Distrowatch while openSUSE is on place 6:
http://distrowatch.com
I googled around before I started and openSUSE was not recommended for
beginners in any article I read. The top proposals for beginners in most
articles were Mint, Ubuntu and Manjaro.
that's why I always install "vanilla" TeXLive instead of the distribution's).
https://www.tug.org/texlive/acquire-netinstall.html
Many thanks, I will try this out.
Manjaro seems to ship its own (command line) package manager ("TeXLive
Local Manager): https://wiki.archlinux.org/index.php/TeX_Live
I found it by googling and it seems to be installed but I cannot find it. But
as you know I cannot use command lines because I don't know the commands and
forget them all the time if I don't use them frequently. That was the reason
why I came to LyX - because I forgot all the time the different LaTeX commands.
The packagers of a distribution decide which dependencies a package has.
Nothing _we_ can do here.
Hmm, that is very bad. I think that explains why software companies don't offer
Linux versions. (I saw yesterday that there are no longer Skype, Adobe Reader
and other useful programs on Linux.) Giving support for all the different
dozens of distributions would be a nightmare if every distribution decides on
its own what to install with a program and what not.
regards Uwe
Hi Uwe,
of course you are entitled to have your own opinion on what is right or
wrong, good or bad. But sorry, your explanation re software companies
not offering Linux versions is far fetched and daring. And what is your
last sentence for - who asked your opinion on the opensource idea?
Thinking twice may help sometimes.
Cheers,
Michael
Re: Fwd: Auto-Re: Typo? (setMessageColour vs setMessageColor) Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #216
Yeas, please do remove it! thanks, Michael Berger On 05/15/2017 08:59 AM, Christian Ridderström wrote: Does everyone get an automatic reply from the account below when posting to lyx-devel, and if so, should we ask Maté to remove him from the list...? Alternatively I suppose I could create a filter to get rid of his auto reply, but that just solves the issue for me. /C PS. Google translate says it means: "your email has been received, thank you. keep in touch!". -- Forwarded message -- From: *李虎* <l...@jscd.gov.cn <mailto:l...@jscd.gov.cn>> Date: 2017-05-15 8:54 GMT+02:00 Subject: Auto-Re: Typo? (setMessageColour vs setMessageColor) Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #216 To: c...@lyx.org <mailto:c...@lyx.org> 邮件已收到，谢谢。保持联系！
problems using LyX 2.1 documents in LyX 2,2.1
Dear all, I have quite a number / variety of documents (domain linguistic and engineering) created with LyX 2.1 and Mageia5 / KDE. It may take some time till Mageia comes along with newer versions of LyX, Latex (this is by no means a negative statement; Mageia is just late but great!) and I decided to use and develop my existing documents in openSUSE Leap 4.2.2, KDE. I now have: LyX 2.2.1-2.9 / Kbibtex 0.6-2.6 / the modules csquotes, fixme, todonotes and LaTeX are stamped 2015.104 Transformation of most of my old documents went seamless while some needed minor adjustments that I could do myself as somebody without any programming knowledge. However, my theses made with Lyx 2.1 / classicthesis-v4.1 and now used with LyX 2.2.1 / classicthesis-v4.2 refuse to export to PDF. They start an endless loop. In the Lyx Documents I cannot see anything nothing wrong; trees in ERT, glosses are there, though the latter look somewhat different. I get no error messages at all. This behavior is identical of both, classicthesis-LyX-v4.2-biblatex_biber and classicthesis-LyX-v4.2-biblatex_bibtex8 I started several attempts to copy the contents of the old child documents into the new child documents but this is slave work and I came to conclude that I might as well rewrite the whole thing from scratch and let everything be as is until Mageia is up to higher versions. But the big question remains whether or not problems like this will then be gone!? After all, is it not Miede's classicthesis that ought to be accordingly adjusted to work with latest versions of LyX and LateX? Any comment is highly appreciated, ideally would be a recipe for making my old classicthesis files work with classicthesis-v4.2 and compile in Lyx 2.2.x :-D Cheers and thanks for your continuing support, Michael
test
this is a test, no action required Michael
Re: footnote numbering in boxes
On 11/19/2016 11:39 AM, Jean-Marc Lasgouttes wrote:
Le 19/11/2016 à 10:25, Michael Berger a écrit :
Dear all,
I observe that numbering of footnotes in boxes is automatically changing
to 'lettering' - see screen shot. Is this intended behavior or could it
be specific to classicthesis? I am not sure to like it or not.
Hello Michael,
All I know is that it is not our doing.
Regards,
JMarc
Hi JMarc, edu Gpl, all,
I found all open questions on the subject answered in: > Help > Embedded
Objects > Notes > Footnotes.
For user colleagues concerned I am citing the most relevant declaratives:
* the numbers (of footnotes) are consecutive; whether the footnotes
are reset for every chapter depends on the document class (they are
in classicthesis)
* footnotes in tables are not printed by Latex due to technical
reasons; but there is a method to print them: instead of the
footnote the command \footnotemark{} is inserted as Tex code and the
text of the footnote is entered as an argument of the Tex code
command \footnotetext{put footnote text here}
* footnotes in a minipage box are printed but inside the box and with
a different numbering (in classicthesis the numbers are replaced by
letters a, b, c) because a minipage box is like a page inside a
page; to get a footnote that is output at the bottom of the page
(like a normal footnote) use above method of \footnotemark{} and
_outside_ the minipage \footnotetext{}
* if in Box Settings the Inner Box is changed from 'Minibox' to
'Parebox' the footnotes will be moved from inside the box to the
bottom of the page and the numbering will be consecutive as normal
Michael
Re: footnote numbering in boxes
On 11/20/2016 08:15 AM, edu Gpl wrote: Please see this link: http://tex.stackexchange.com/questions/106306/using-footnotemark-with-letters Best regards بتاريخ ١٩/١١/٢٠١٦ ١٢:٢٧ م، كتب "Michael Berger" <id...@online.de <mailto:id...@online.de>>: Dear all, I observe that numbering of footnotes in boxes is automatically changing to 'lettering' - see screen shot. Is this intended behavior or could it be specific to classicthesis? I am not sure to like it or not. Any comment is appreciated. I am using Lyx 2.2.2, texlive 2016, Miede's classicthesis 4.2 Thanks & cheers, Michael Thanks edu Gpl, but I did not change/add any code of my footnotes. I prefer to have *all* footnotes numbered and put at the end of the page - never inside a box. These two footnotes were there already in the text and numbered and they were put at the end of the page. Then I selected that part of the text as a box, the footnotes moved from the end of the page inside the box and had their numbers replaced by letters. So, I take it this is sort of an automatism. Anyway, I can now use the code found in your link to reverse this automatism. Thanks and regards, Michael
footnote numbering in boxes
Dear all, I observe that numbering of footnotes in boxes is automatically changing to 'lettering' - see screen shot. Is this intended behavior or could it be specific to classicthesis? I am not sure to like it or not. Any comment is appreciated. I am using Lyx 2.2.2, texlive 2016, Miede's classicthesis 4.2 Thanks & cheers, Michael
Re: Allow application of insets to all selected table cells
On 11/10/2016 12:25 PM, racoon wrote: If several table cells are selected but *not* the whole table, insets cannot be inserted. I suggest that instead they can be inserted and the obvious mode of insertion seems to be to apply the inset for each table cell individually. One possible use case I just came across was that I wanted to Alert two columns of a larger table in beamer. I had to go through each cell and click on the Text Style > Alert. Would be nice to not having to do that. Daniel By the way, did you know that "Beamer" is the German word for "projector"? Germans have so many funny words that sound English but are not. Another is "Handy" which is the word for "mobile phone". Hi racoon, Sorry to have to correct you ;-) 'Beamer' is no German word at all (by origin) as the pronunciation proofs, and therefore cannot be the German word for 'projector'. This is not withstanding the fact that Germans do use the English word 'beamer' in the same way as they nowadays use so many other English words, e.g. the word 'cool'. This is trendy, nothing else. The German word for 'projector' is 'Projektor'. PS: and the words "Kindergarten"and "Poltergeist" are German and both are used in the English speaking world as well. And by the way, did you know that 60 - 70% of English words derive from Latin (as does the word 'projector')? Note: we are about to misusing the list >:o Sorry and Cheers! Michael
Re: Assertion from Insert>Special Character
On 11/01/2016 09:56 PM, Andrew Parsloe wrote: I tried out Insert>Special Character>Symbols in response to an email to the list from Michael Berger and triggered an assertion. (LyX 2.2.2 on Windows 7) Recipe: in a new document Insert>Special Character>Symbols>Mathematical Alphanumeric Symbols Insert any symbol from this group Select the symbol, copy, paste You may need to repeat the last step. Sometimes the assertion is triggered at the first attempt to copy, sometimes after pasting and then selecting to copy the now two symbols. The assertion message references Paragraph.cpp, line 1723. Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus Thanks Andrew, Scott I tried as you suggested but it does not work here (LyX 2.2.2 Linux, Mageia5, KDE, TL2016) Each new symbol produced with copy and paste or cut and paste returns its own new inputenc error like before. Michael
Insert>Special Character> Symbols does not work in Lyx 2.2.2
Dear all, Mageia5, Lyx 2.2.2, Texlive2016, using classicthesis-LyX-v4.2_biblatex_biber In body text I try using using Insert > Special Character > Symbols > any category (e.g. Mathematical Operator) This worked in Lyx 2.1 but in Lyx 2.2.2 either an error is thrown out or nothing happens when compiling to PDF. Classicthesis uses Language Encoding Unicode (utf8). Is this a known issue? Are there alternatives to get the symbols right in my text? Thanks and cheers, Michael
Re: Fwd: Nomenclature in TOC different/unexpected in LyX2.1 vs Lyx2,2.2
On 10/26/2016 09:55 AM, Jürgen Spitzmüller wrote:
Am Mittwoch, den 26.10.2016, 08:07 +0200 schrieb Michael Berger:
Dear developers,
I am forwarding my initial e-mail to you because I found that the
behavior described is not specific to classicthesis.
Other document classes (I checked Komascript Article and Article
Standard) show a similar behavior. That makes me believe it is a LyX
2.2.2 , 2.2.x etc. issue.
Can you help, please?
Michael, you should know by now that we need a minimal example LyX file
to reproduce the error. Screenshots are not much useful.
Jürgen
Michael
Jürgen, this time you taught me a clear lesson - I will remember it,
for sure!:-D
I had the mini example ready to be sent and then reassambled what I was
about to do.
Checking the Latex preamble over again I starred at the following line:
\def\nompreamble{\addcontentsline{toc}{section}{\nomname}\markboth{\nomname}{\nomname}}
and that looked so bloody guilty!
Beat me - I do not recall how and why it got there but killing it solved
my problem: see snapshot.
Is this line of any use ever or may I scrap it for good?
So, it is no issue of Lyx etc. but simply (as always) my own incompetence.
Sorry once more and thanks for your continuing patience! ;-)
Michael
Re: Fwd: Nomenclature in TOC different/unexpected in LyX2.1 vs Lyx2,2.2
On 10/26/2016 09:55 AM, Jürgen Spitzmüller wrote:
Am Mittwoch, den 26.10.2016, 08:07 +0200 schrieb Michael Berger:
Dear developers,
I am forwarding my initial e-mail to you because I found that the
behavior described is not specific to classicthesis.
Other document classes (I checked Komascript Article and Article
Standard) show a similar behavior. That makes me believe it is a LyX
2.2.2 , 2.2.x etc. issue.
Can you help, please?
Michael, you should know by now that we need a minimal example LyX file
to reproduce the error. Screenshots are not much useful.
Jürgen
Michael
Jürgen, this time you taught me a clear lesson - I will remember it,
for sure!:-D
I had the mini example ready to be sent and - as always - I reassembled
what I was about to do.
And then I starred at this line in the Latex preamble:
\def\nompreamble{\addcontentsline{toc}{section}{\nomname}\markboth{\nomname}{\nomname}}
And that looked so bloody guilty!
I removed it and the problem was solved, that is the extra useless.
Don't asked me why and how it got there - I do not recall!
Is it of any use or may I scrap it forever?
Sorry again and thanks for your continuing patience!
Michael
nomencl.lyx
Description: application/lyx
@comment{x-kbibtex-encoding=utf-8}
% % % % % This file was created with JabRef 2.10.
@article{ReeGar03,
author = {Rees, Bronwen and Garnsey, Elizabeth},
journal = {Gender, Work \& Organization},
number = {5},
pages = {551â578},
title = {Analysing competence: Gender and identity at work},
volume = {10},
year = {2003}
}
Re: Fwd: two indexes: one has black and the other blue page numbers
On 09/24/2016 02:11 PM, Jürgen Spitzmüller wrote:
Am Samstag, den 24.09.2016, 14:05 +0200 schrieb Michael Berger:
this works very well in a number of my documents.
But the thesis I am currently working on also needs the bibtoc
package,
When applying this workaround I get:
Latex Error: Missing \begin{document}
Latex Error: Option clash for package hyperref
Description: \usepackage{bibtopic}
As much as I hate to bother you again I dare ask if you could fix
this
too? ;-)
Running out of time, sorry. I suppose that your class (classicthesis?)
loads hyperref. You could edit that file and insert \usepackage{fixme}
before hyperref is loaded (and of course remove the preamble code from
the LyX document).
If this doesn't help, you will have to do without fixme.
Jürgen
Michael
Will finish my Masterthesis (classicthesis) without fixme.
Michael
Re: Fwd: two indexes: one has black and the other blue page numbers
On 09/24/2016 01:01 PM, Michael Berger wrote:
Dear Jürgen,
tough struggle but in the end just GREAT!
Thanks,
Michael
On 09/24/2016 12:13 PM, Jürgen Spitzmüller wrote:
Taking back to the list, since others might be interested as well what
the problem is.
(Michael wrote me in PM that the problem persists with the most recent
modules for 2.1.)
It turns out the problem is that fixme needs to be loaded before
hyperref. This is what LyX 2.2 does, but LyX 2.1 can't do (since fixme
is not yet integrated).
In LyX 2.1, if you need to use fixme in this context, the only
workaround is to disable "PDF Support" in Document > Settings and load
hyperref manually in the preamble.
See attached file.
Jürgen
Dear Jürgen,
this works very well in a number of my documents.
But the thesis I am currently working on also needs the bibtoc package,
When applying this workaround I get:
Latex Error: Missing \begin{document}
Latex Error: Option clash for package hyperref
Description: \usepackage{bibtopic}
As much as I hate to bother you again I dare ask if you could fix this
too? ;-)
Michael
Re: Fwd: two indexes: one has black and the other blue page numbers
Dear Jürgen, tough struggle but in the end just GREAT! Thanks, Michael On 09/24/2016 12:13 PM, Jürgen Spitzmüller wrote: Taking back to the list, since others might be interested as well what the problem is. (Michael wrote me in PM that the problem persists with the most recent modules for 2.1.) It turns out the problem is that fixme needs to be loaded before hyperref. This is what LyX 2.2 does, but LyX 2.1 can't do (since fixme is not yet integrated). In LyX 2.1, if you need to use fixme in this context, the only workaround is to disable "PDF Support" in Document > Settings and load hyperref manually in the preamble. See attached file. Jürgen
Re: Fwd: two indexes: one has black and the other blue page numbers
On 09/23/2016 10:42 AM, Jürgen Spitzmüller wrote: Am Freitag, den 23.09.2016, 09:37 +0200 schrieb Michael Berger: Dear Jürgen, I trust this new mini example will serve your purpose. It is on Koma-Script Article and not on classicthesis. However, its behavior is identical - removing the module 'FiXme' produces a correct PDF output with colored page numbers in both index lists. I get correct colors also with these modules. I suspect you have old versions of these modules in your personal LyX directory (~/.lyx/layouts). Remove them and I bet it will work (all those modules are now included in the LyX distribution). HTH Jürgen Thanks and cheers! Michael Dear Jürgen, in ~/,lyx/layouts I have not a single module but the file 'lyxmodules-lst' which declares modules and their associated definition files. I checked and found 'fixme.sty' and all the other modules listed in there. In my system 'fixme.sty' is found here: /usr/share/texmf-dist/tex/latex/fixme/fixme.sty and the other modules likewise. Lyx 2.1.3; Mageia5 up to date; There are seven texlive bundles of version 20130530 I am not in real need of using FiXme and could go on without using it. So, please, you should not invest more of your time unless, of course, you have other good reasons to. ;-) Cheers, Michael PS: I never encountered problems in using other modules
Re: Fwd: two indexes: one has black and the other blue page numbers
On 09/22/2016 08:22 AM, Jürgen Spitzmüller wrote: Am Donnerstag, den 22.09.2016, 05:08 +0200 schrieb Michael Berger: Dear Jürgen, talking to an expert always rewards - in one way or another. In the course of making the mini file 'less complex' I removed all loaded modules except 'Linguistics'. And that solved the problem. Loading the module FiXme again had the problem return. Removing FiXme in my real document solved the problem there as well. I found 'fixme.sty ... modified 28.01.2013' - is this of relevance? Maybe, but as long as you do not provide a real minimal example, I cannot really help. Jürgen Thanks again and cheers! Michael Dear Jürgen, I trust this new mini example will serve your purpose. It is on Koma-Script Article and not on classicthesis. However, its behavior is identical - removing the module 'FiXme' produces a correct PDF output with colored page numbers in both index lists. Thanks and cheers! Michael indexcolor.lyx Description: application/lyx
Re: Fwd: two indexes: one has black and the other blue page numbers
On 09/21/2016 05:29 PM, Jürgen Spitzmüller wrote: Am Mittwoch, den 21.09.2016, 17:05 +0200 schrieb Michael Berger: Dear jürgen, thanks for being prepared to look into this. Hope this mini file is informative enough. No, it is not. This file does not compile here, since it requires child documents and bibliography data that are not included, and it is way too complex. Please reduce it to a form that can be compiled, that is really minimal and exposes the problem. See http://wiki.lyx.org/FAQ/MinimalExample Jürgen I am keeping my fingers crossed. Michael Dear Jürgen, talking to an expert always rewards - in one way or another. In the course of making the mini file 'less complex' I removed all loaded modules except 'Linguistics'. And that solved the problem. Loading the module FiXme again had the problem return. Removing FiXme in my real document solved the problem there as well. I found 'fixme.sty ... modified 28.01.2013' - is this of relevance? Thanks again and cheers! Michael
Re: Fwd: two indexes: one has black and the other blue page numbers
On 09/21/2016 11:44 AM, Jürgen Spitzmüller wrote: Am Mittwoch, den 21.09.2016, 08:48 +0200 schrieb Michael Berger: Dear developers of Lyx, I am still left with this (minor) problem. So, perhaps somebody can give some advice!? I checked both the 'classicthesis-config.tex' and 'classicthesis.sty' files but as a layman found no way to correct this. So, could it be a Lyx problem? We cannot help without a minimal example file. Jürgen thanks and cheers, Michael Dear jürgen, thanks for being prepared to look into this. Hope this mini file is informative enough. I am keeping my fingers crossed. Michael indexcolor.lyx Description: application/lyx
Fwd: multiple indexes
Dear developers of Lyx, I am still left with this (minor) problem. So, perhaps somebody can give some advice!? I checked both the 'classicthesis-config.tex' and 'classicthesis.sty' files but as a layman found no way to correct this. So, could it be a Lyx problem? thanks and cheers, Michael Forwarded Message Subject:multiple indexes Date: Fri, 16 Sep 2016 12:53:31 +0200 From: Michael Berger <id...@online.de> To: lyx-users <lyx-us...@lists.lyx.org> Dear LyX users, I am using multiple indexes (two different indexes) in my document. The (back referenced) page numbers in one print blue while black in the other one. I should add that cross references appear blue as well as the referenced page numbers in table of contents, in nomenclature, in bibliographies etc. I am using 'classicthesis-Lyx-v4.1' Any hint as to why this happens and how it could possibly be corrected? Thanks, Michael
Re: Enable View master document even if there are no child documents
On 08/29/2016 04:48 PM, racoon wrote: On 29.08.2016 15:28, Michael Berger wrote: Are you sure to have understood the concept of master-child? Michael On 08/29/2016 12:22 PM, racoon wrote: Hi, I almost never View child documents. Most of the time they don't compile properly on their own anyway. So I would like to remove the View button from my interface. Unfortunately, the View master document button is grayed out if there are no child documents in a "master". Is that on purpose? Why not enable it anyway? So one normally presses one and the same button and only for the extraordinary circumstance of viewing a child document has to press another button. Maybe, you had in mind what is written in the User Guide: "[The View Master Document] menu item is only visible if your document is included to another document, which is then its “master” (see section Child Documents in the Embedded Objects manual for more information on this topic)." (A.6.8) This seems just plain wrong. The menu item (and the toolbar button) is visible in any master document as well. Daniel No Daniel, the 'Select default master document' is open as you might want to use it as a child in another document, the then master. So you should not be to much concerned about this. When you use/create/include a child document using > Insert > File > Child Document you will be presented the Child Documents option in the Documents Setting dialogue. And to me this is correct behavior. If you do use child documents then the settings and preamble are stored in the master will rule (although there are some exceptions, e.g. modules that need to be set in a child's preamble). That too is proper behavior in my opinion because otherwise you would have to write preambles and settings for each single child document. And you would not use the master-child concept for small documents - would you? Now, as a consequence you most probably get an error when trying to compile a child document because it needs the settings of the master. You have to save the child first and then compile the master. That is why I think your statement 'Most of the time they don't compile properly on their own anyway' is inappropriate. Hope that I did not misunderstand you but this is what I have here. Cheers, Michael
Re: Enable View master document even if there are no child documents
Are you sure to have understood the concept of master-child? Michael On 08/29/2016 12:22 PM, racoon wrote: Hi, I almost never View child documents. Most of the time they don't compile properly on their own anyway. So I would like to remove the View button from my interface. Unfortunately, the View master document button is grayed out if there are no child documents in a "master". Is that on purpose? Why not enable it anyway? So one normally presses one and the same button and only for the extraordinary circumstance of viewing a child document has to press another button. Daniel
Re: Bullet icon different in lyx and pdf
On 07/25/2016 04:52 PM, Anand Rangarajan wrote: I don't know if this bug has already been documented but a cursory search didn't find anything related. When I change a bullet appearance in lyx via Documents --> Settings --> Bullets --> Level and then pick a bullet icon, the icon for the bullet does not change within the Itemize environment inside lyx. It does however work correctly in the pdf. To reiterate, while lyx shows the wrong bullet icon after it has been changed (as described above), the pdf is correctly generated. lyx and pdf test files attached. I'm on lyx-2.2.1, opensuse 42.1 (Qt 4 frontend and not Qt 5). Anand Hi Anand, there is nothing wrong. This is normal behavior. This is Linux, so what you see is NOT what you get. Almost nothing in your LyX document looks like the (PDF) output. Michael
Re: using older Lyx documents after upgrading
On 07/20/2016 02:19 AM, Scott Kostyshak wrote: On Tue, Jul 19, 2016 at 12:50:19PM +0200, Michael Berger wrote: Hi all, this is to share my experience with other users and asking for help from the developers. ;-) I have quite a number of LyX documents made in Mageia5 using LyX 2.1; TexLive 2013; classicthesis-LyX-v4.1, most of them with the module 'Linguistics' loaded and using different bibliography styles. After upgrading to LyX 2.2.0; TexLive2016; classicthesis-LyX-v4.2 and loading those older documents I found the following when trying to export to PDF: I don't know much about this stuff, but in general you do not want to upgrade several critical components at once. Ideally you should upgrade one system (e.g. LyX), test, if everything goes well, upgrade another system (e.g. Koma-Script), test, etc. And whenever you upgrade, you should always make sure you can easily downgrade. If you can't easily go back to how you had it before, take a step back and ask yourself "do I really need to upgrade"? You will learn through frustration that upgrades break things. This will always be true. But since you are learning more about Linux you will learn how to create a robust workflow and how to easily go back to how you had things before. Sounds like a frustrating issue. I hope you find a solution and don't have to redo all of the documents! Best of luck, Scott Thanks Scott, good comment, very basic but nevertheless quite true: there is no such thing like a general recipe or one single reason if things don't work as expected after such radical upgrades. To be frank, I am surprised that by now all but two my of old documents (Miede's classicthesis) do compile after changing/adapting just one or two details - most documents compiled off the cuff! And for these two last documents I found my way: a combination of copy and/or redoing other parts. And yes, I could always go back (there were situations when I thought to just forget about this whole dam.. idea) without loosing a bit because this exercise is done on a separate experimental computer while all my work is still there and save on another machine. Forgetting the frustration and thinking of the benefits and learning effects I have no regrets :-D. Cheers! Michael
using older Lyx documents after upgrading
Hi all, this is to share my experience with other users and asking for help from the developers. ;-) I have quite a number of LyX documents made in Mageia5 using LyX 2.1; TexLive 2013; classicthesis-LyX-v4.1, most of them with the module 'Linguistics' loaded and using different bibliography styles. After upgrading to LyX 2.2.0; TexLive2016; classicthesis-LyX-v4.2 and loading those older documents I found the following when trying to export to PDF: * Beamer presentations > OK * All types of Koma-Script documents >> basically OK with some minor adjustments, inter alia regarding the bibliography style, e.g. oscola * classicthesis-LyX-v4.2_biblatex_biber and classicthesis-LyX-v4.2_biblatex_bibtex8 >> do compile all example files as well as their original 'ClassicThesis.lyx' template without any problem. * but trying to compile any of my classicthesis-LyX-v4.1 documents I get either an endless loop or heaps of errors - there are so many different errors that I eventually gave up trying to fix them I also started copying parts of my old documents into a new one but even text that I considered not very special produced errors. Authoring everything entirely new seems to be the only way as far as I see now. Well is that it? Any explanation, clue, advice etc. is highly appreciated. Cheers and thanks, Michael
Re: Question on installation of Lyx from distro and/or over internet
On 07/14/2016 11:56 PM, Jean-Pierre Chrétien wrote: Le 14/07/2016 07:13, Buenas Noticias a écrit : Hi Michael: TeXlive can work because each is in a different folder and you are the one you decide on your route which you work (/usr/local/texlive/2013 or 2016). I think that if you have installed an earlier version of lyx and install later, the lyx executable will be overwritten and the current work anymore. You may install a more recent version of lyx and keep both version running (the one which comes with your version manager and the one you install yourself) by running ./configure with option --with-version-suffix. /usr/bin/lyx will call lyx-2.1 and /usr/local/bin/lyx-2.2.0 will call lyx-2.2. tex2lyx and lyxclient will be suffixed as well, and your local changes will lie in ~/.lyx and ~/.lyx-2.2.0 Thanks Jean-Pierre, that explains precisely what needed to be done (in case) and how it would function! Your explanation adds to my very limited comprehension of such system. Michael
Question on installation of Lyx from distro and/or over internet
Mageia5's software manager offers to install LyX 2.1 and if done will automatically install Texlive 2013 along with it. I decided to install the most recent versions available and found LyX 2.2 and Texlive 2016 that could be installed over the internet. Thinking of possible conflicts I removed Lyx 2.1 and Texlive2013 and then installed first Texlive2016 (as user) and then LyX 2.2 (as administrator). Meanwhile things are running as I want them to. Question: Would there have been a conflict without prior removal of the old versions? Or putting it the other way around: Would there be a conflict if installing these older versions again using Mageia's software manager and then have both versions installed? PS: I think there is an option to mark packages as "never install" or something. Thanks and cheers, Michael
Re: writing glosses in any KOMA-Script document class throws Class scrXXXX Error: undefined old font command '\it'
On 07/08/2016 04:44 PM, Jürgen Spitzmüller wrote: Am Freitag, den 08.07.2016, 15:08 +0200 schrieb Michael Berger: A short while ago I had posted the user list on the Error: undefined old font command '\it' (\rm). As I wrote on lyx-users, the error is fixed in version 1.1 of covington.sty which has been published yesterday: http://www.ctan.org/pkg/covington Please update to this version (with TeXLive, the new version should get to you automatically when doing an update with the TeXLive manager). Jürgen Thanks Jürgen, it is done and works! Michael
Re: installing lyx 2.2.0
On 07/08/2016 06:33 PM, Pavel Sanda wrote: Michael Berger wrote: Hi, 'make' returns errors as per screenshots. Could somebody help? Thanks, Michael Just to make sure - you started compiling from _clean_ tree where no previous experiments/compilations were done, correct? Thanks Pavel, yes I definitely did with the very first installation. But after that I lost somehow control. Meanwhile my problem is solved and lyx 2.2.0 is running (although I might have to do some minor adjustments in some of my old files made with TL2013 and Lyx 2.1). Don't ask me how exactly this was accomplished. I reckon there must have been other obstacles from previous failed attempts that overlapped/interfered with the installation. Furthermore, one or two proposals made by users may perhaps have been counterproductive. When Jürgen informed that he took over maintenance of covington and made some necessary fixes I made a fresh attempt last night. I removed everything that could have to do with LyX 2.1, Tex Live etc. installed by Mageia's software manger and started to install Lyx 2.2.0 as administrator. The installation ran through without complaints. Sorry for the efforts you took and your time invested - but in lack of knowledge my strength is just doggedness and motivation. Michael
installing lyx 2.2.0
Hi,
'make' returns errors as per screenshots.
Could somebody help?
Thanks,
Michael
[mb39@localhost ~]$ cd /home/mb39/Downloads/lyx-2.2.0
[mb39@localhost lyx-2.2.0]$ ./configure
configuring LyX version 2.2.0
checking for build type... release
checking for version suffix...
checking whether Qt5 is requested... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking what packaging should be used... posix
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '1000' is supported by ustar format... yes
checking whether GID '1000' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking whether make supports nested variables... (cached) yes
checking for a Python interpreter with version >= 2.7.0 or 3.3.0... python
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.7/site-packages
checking for python extension module directory...
${exec_prefix}/lib64/python2.7/site-packages
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for ranlib... ranlib
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... no
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether the compiler is clang... no
checking whether STL is libstdc++... yes
checking whether STL is libstdc++ using the C++11 ABI... no
checking whether the compiler implements C++11... yes
checking regex usability... yes
checking regex presence... yes
checking for regex... yes
checking for correct regex implementation... yes
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... no
checking whether gcc accepts -g... no
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for extra library directory... NONE
checking for extra include directory... NONE
checking for extra lib+include directory... NONE
checking for main in -lshlwapi... no
checking for main in -lpsapi... no
checking for main in -lgdi32... no
checking whether to use included boost library... yes
checking whether to use included MyThes library... yes
checking whether byte ordering is bigendian... no
checking whether printing callstack is possible... yes
checking size of wchar_t... 4
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for working iconv... yes
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t
writing glosses in any KOMA-Script document class throws Class scrXXXX Error: undefined old font command '\it'
Dear developers and users of LyX, My sandbox PC: Mageia5 (working for months without problems with Tex Live2013) Then I installed Tex Live2016 GUI (fully editable as user) But I am still using LyX 2.1.3 (installation of LyX 2.2.0 fails because 'make' stops with errors) LyX Preferences PATH prefix: /usr/local/texlive/2016/bin/x86_64-linux A short while ago I had posted the user list on the Error: undefined old font command '\it' (\rm). Now it looks as if I could narrow in the problem: - prior to installing TL2016 I could open and export to PDF any document with or without glosses and regardless their document class - after having TL2016 installed I can still open and export to PDF any document with or without glosses *as long as they do not use **any KOMA-Script class**. *See screenshot This seems irrational insofar as I had never seen this error when using the older Tex Live2013 whereas it appears now after installing TxLive2016, the latest available version. TL GUI shows the various scrxxx classes installed along with the following packages: bidi koma-script mcaption semproc simurgh tex4ht tudscr xepersian I could not uninstall any of these because of their dependencies. PS: Miede's classicthesis-LyX-v4.2_biblatex_biber /...biblatex_bibtex8 show exactly the same behavior and so does classicthesis-LyX-v4.1 I hope with appreciation that you (plural) will find the time to attend to this problem. Thanks and cheers, Michael
Re: makefile errors 'recipe for target 'lyx' failed / ..for target 'all' failed
On 07/04/2016 08:51 PM, Stephan Witt wrote: Am 04.07.2016 um 12:44 schrieb Michael Berger <id...@online.de>: Dear LyX friends, Richard Heck suggested to post this to the list. This is my sandbox PC Mageia5 x86_64 KDE (performing since months without any problem) No older Lyx version installed TexLive2016 GUI installed and functioning I started to install Lyx 2.2.0 ./configure went through and I was encouraged: 'Type make to compile the program.' But 'make' stopped and presented me the errors as per subject. I could repeat this and always got same errors. See also the log attached. Could somebody please help? Your log is really short. It looks like you did some compiler runs before. Did you start from a clean source and build tree after your last call to configure? I suspect you did your build with different configurations. Stephan Thanks Stephan, I try to recall what I did. - Re-install Mageia5 to make sure to have nothing else left on my machine. - Update Mageia5 - Install Tex Live2016 (that wasn't a smooth process but in the end completed) At this point not any version of Lyx and nor any texlive2013 components are present - Download, unpack and install LyX 2.2.0 - ./configure completed - make >>> and here the error in question appeared - make a couple of times again >>> and the exact error in question appeared As all this is done on a sandbox computer and no damage can be done I am prepared to go back as far as necessary. I highly appreciate your advice on this. Thanks and cheers, Michael PS: after the initial configuration the system fell back to the built file format. Thus I added the missing 'libmagic library' and its components and did ./configure again. Now the log was very much longer but stopped with exactly the same error.
makefile errors 'recipe for target 'lyx' failed / ..for target 'all' failed
Dear LyX friends,
Richard Heck suggested to post this to the list.
This is my sandbox PC
Mageia5 x86_64 KDE (performing since months without any problem)
No older Lyx version installed
TexLive2016 GUI installed and functioning
I started to install Lyx 2.2.0
./configure
went through and I was encouraged: 'Type make to compile the program.'
But 'make' stopped and presented me the errors as per subject.
I could repeat this and always got same errors.
See also the log attached.
Could somebody please help?
Thanks and cheers,
Michael
[mb39@localhost ~]$ cd /home/mb39/Downloads/lyx-2.2.0
[mb39@localhost lyx-2.2.0]$ ./configure
configuring LyX version 2.2.0
checking for build type... release
checking for version suffix...
checking whether Qt5 is requested... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking what packaging should be used... posix
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '1000' is supported by ustar format... yes
checking whether GID '1000' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking whether make supports nested variables... (cached) yes
checking for a Python interpreter with version >= 2.7.0 or 3.3.0... python
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.7/site-packages
checking for python extension module directory...
${exec_prefix}/lib64/python2.7/site-packages
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for ranlib... ranlib
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... no
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether the compiler is clang... no
checking whether STL is libstdc++... yes
checking whether STL is libstdc++ using the C++11 ABI... no
checking whether the compiler implements C++11... yes
checking regex usability... yes
checking regex presence... yes
checking for regex... yes
checking for correct regex implementation... yes
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... no
checking whether gcc accepts -g... no
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for extra library directory... NONE
checking for extra include directory... NONE
checking for extra lib+include directory... NONE
checking for main in -lshlwapi... no
checking for main in -lpsapi... no
checking for main in -lgdi32... no
checking whether to use included boost library... yes
checking whether to use included MyThes library... yes
checking whether byte ordering is bigendian... no
checking whether printing callstack is possible... yes
checking size of wchar_t... 4
checking for ld used by GCC... /usr/bin/ld
checking if the linker
