Re: Double dash in Lyx 2.2.1 is not printed correctly

[Georg Baum]

Danko Georgiev wrote:

> Dear Scott,
> 
> If you try typesetting time periods, in old LyX you could just type
> "2014--2016". When you print PDF you will read 2014[en-dash]2016. In
> other words, old Lyx printed the double dash as if it Latex code.

Yes. This behaviour caused lots of trouble (e.g. 
http://www.lyx.org/trac/ticket/3647, http://www.lyx.org/trac/ticket/8561) 
and has been changed in version 2.2. Now a hyphen that is stored in a LyX 
document is always typeset as a hyphen, even for two or more consecutive 
hyphens.

> Now in version 2.2.1 I tried to type 2014--2016 but Lyx automatically
> overwrites this double dash with en-dash. This is simply WRONG thing to
> do. en-dash is a special character that I do not want in my code!

This conversion was implemented in order to mimic the 2.1 behaviour. In 2.1 
if you enter two consecutive hyphens, you get an en-dash in the output. In 
2.2, if you enter two consecutive hyphens, you get an en-dash in the output 
as well. The only difference is that in 2.2, the display on screen and the 
contents in the .lyx file are also copnsistent with the output.

> To make it clear: imagine that I want to type $\mu$ and LyX starts to
> convert this to unicode character mu U+039C, Μ or whatever

You can always enter - - and then delete the space if you really need two 
consecutive hyphens.

> Lyx now behaves as MS Word instead as a LaTeX typesetter. I don't think
> the solution is to revert back my LyX to 2.1

We could of course change the automatic conversion of consecutive hyphens on 
input if there is popular demand. That would make entering of en-dashes and 
em-dashes more difficult, and currently I believe that the current behaviour 
is convenient for most users.

> On 07-Sep-16 19:06, Scott Kostyshak wrote:
>> On Wed, Sep 07, 2016 at 07:02:58PM +0300, Danko Georgiev wrote:
>>> Hello,
>>>
>>> I have just updated to the newest LyX 2.2.1. and immediately got a
>>> problem with automatic conversion of double dashes -- to en-dash in a
>>> manuscript written with Lyx 2.1. This en-dash replacement resulted in
>>> error message in index sorting when compiling PDF.

If a document that produces PDF output does not produce the same PDF output 
anymore after loading it in 2.2 then this is a bug. Please file it at 
http://www.lyx.org/trac/wiki/BugTrackerHome and include a test case in 2.1 
format.


Georg

Re: LyX 2.2.1 is not running

[Georg Baum]

Richard Heck wrote:

> On 07/26/2016 01:09 PM, Scott Kostyshak wrote:
>> On Tue, Jul 26, 2016 at 02:54:36PM +0100, Dr Eberhard Lisse wrote:
>>> But from another thread, have you tried to download and install:
>>>
>>> https://www.microsoft.com/en-US/download/details.aspx?id=48145
>> The above worked for another LyX user who had the same problem [1].
> 
> Uwe, is this an issue with the package we provide? Or is it independent?

It is an installer issue. The LyX installer does not call the official MSVC 
redistributables installer, but includes the MSVC dlls instead. This might 
work on some machines and might not work on some others (the official 
installer does more than just copying dlls to some place).


Georg

Re: forthcoming installation of Lyx 2.2

[Georg Baum]

Michael Berger wrote:

> Hi all,
> I have Mageia5 / KDE and just succeeded to install texlive2016.
> The next challenge is to install Lyx 2.2 from http://www.lyx.org/Download
> 
> i am addressing those of you who already successfully did this.
> 
> Is there anything to be observed/prepared/considered prior to starting
> the installation?

Since there is no binary package for Mageia5 you will need to compile from 
source. This is easy, the file INSTALL in the LyX source package lists some 
instructions. However, it might be a bit more difficult to find out how 
exactly the prerequisite packages are called on Mageia5, e.g. the 
development package for qt. If a prerequiste is missing then the configure 
script will tell you, and if you don't find the correct package to install 
then ask on the list, probably someone will know how to find the package 
from the configure error message.


Georg

Re: Missing icons after upgrading to LyX 2.2.0

[Georg Baum]

John Kane wrote:

> john@john-K53U:~$  apt-get -f install
> E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission
> denied)
> E: Unable to lock the administration directory (/var/lib/dpkg/), are you
> root?
> john@john-K53U:~$  apt-get -f install lyx
> E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission
> denied)
> E: Unable to lock the administration directory (/var/lib/dpkg/), are you
> root?
> john@john-K53U:~$

This happens if at the same time some other package management tool is 
running and holds a lock on the database. Assuming that you don't do that 
yourself, the most likely reason is an automatic 'apt-get update' running in 
the background from cron. You would see the process in the output of

ps -axu | grep root

and usually it would not take long to be finished, so you could try again.


Georg

Re: LyX-related Hiccup when installing system updates

[Georg Baum]

Jacob Bishop wrote:

> I am on Linux Mint 17, using the lyx-devel/release ppa. When I tried to
> install the regular system updates today using the update manager, it
> failed with the message,
> 
> E:/var/cache/apt/archives/lyx_2.2.0-1~trusty~ppa3_amd64.deb: trying to
> overwrite '/usr/share/icons/hicolor/scalable/apps/lyx.svg', which is also
> in package lyx-common 2.1.4-1~trusty~ppa1
> 
> I'm not sure I understand what exactly the problem is or was, but I
> resolved the problem by running.

It is a packaging error. lyx.svg should not be in 
lyx_2.2.0-1~trusty~ppa3_amd64.deb, but in lyx-
common_2.2.0-1~trusty~ppa3_amd64.deb. In case I missed something and the 
file was moved on purpose it was not done correctly: In this case the 
package lyx (version 2.2.0) needs to declare a conflict against lyx-common 
(versions older than 2.2.9). Then the package manager knows that the old 
lyx-common needs to be removed before installing thew new lyx.


Georg

Re: Missing icons after upgrading to LyX 2.2.0

[Georg Baum]

John Kane wrote:

> I installedl from what I believe is a prepackaged binary from Liviu
> Andronic's  stable PPA
>  which I have used
> before.

Good.

> My installed version of qt is qt4.5 which if I am reading the release
> notes correctly should be okay.

4.5 is really old, and although LyX should work with it in principle it is 
not well tested. Somehow I cannot believe that the ppa contains packages for 
such an old version, but Liviu will know more.


Georg

Re: Missing icons after upgrading to LyX 2.2.0

[Georg Baum]

John Kane wrote:

>  I just did an upgrade to LyX 2.2.0 successfully for the most part but my
> menu toolbar has turned to text—there are no icons! See attached
> screenshot. Note that the menu toolbar and the math toolbar are both in
> text. The splash screen icon is there.
> A quick look at usr/share/lyx/ui shows four files, default.ui,
> stdcontex.inc, stdmenus.inc, & stdtoolbars.inc, all of which look okay.
> Unfortunately I have no idea were to look for the actual icons (.svg
> files?).
> Any suggestions would be appreciated
> LyX 2.2.0 Ubuntu 16.04

LyX 2.2.0 requires a qt with SVG support compiled in (as mentioned in 
RELEASE_NOTES). This looks like your qt does not have proper SVG support. 
Which qt version are you using? Did you compile from source or install some 
prepackaged binary?


Georg

Re: lyx2.2.0rc1 and lyx2.2.0 identical?

[Georg Baum]

Scott Kostyshak wrote:

> On Tue, May 31, 2016 at 09:10:17AM +0200, Wolfgang Engelmann wrote:
>> 
>> How do I effectively remove the rc1 lyx. I have it and 2.2.0 (myx lyx22)
>> side by side
> 
> You're on Linux right? I'm not sure of the best way to remove it. We
> don't have an uninstall target (i.e. you can't do "make uninstall").

We do (at least with autotools). Simply call

make uninstall

from the rc1 build directory. If installation needed root privileges, then 
this needs root privileges as well.


Georg

Re: Help with math environment translations for LyX

[Georg Baum]

febty febriani wrote:

> Dear lyx team
> 
> The translation of some words in  Indonesia is not correct. How to correct
> them? Just write them in this thread?

Yes please do so.


Georg

Re: Help with math environment translations for LyX

[Georg Baum]

Helge Hafting wrote:

> The translation of  "List of listings" for Norwegian (nb) seems fine.

Many thanks for the review. The changed translation is in.


Georg

Re: Help with math environment translations for LyX

[Georg Baum]

edu Gpl wrote:

> Dearlyx team
> arabic translation is correct.
> 
> regards
> 
> lyx arabic translator

Many thanks for the review, I updated the translation status.


Georg

Re: trouble submitting IEEE conference article

[Georg Baum]

Neal Becker wrote:

> Seems pretty messed up.  If I don't check 'use non-tex fonts', and export
> via DVI (LuaTeX), I get a dvi, but no eps graphics.

This is a bug. It would be nice if you could attach a minimal example to the 
report you made.

> Finally, I tried export LaTeX (dviluatex), and THEN I got eps graphics,
> but without mangled names.

This is expected. If you export to LaTeX (any flavour) LyX assumes that you 
want to further edit the files. Thus it does not do any file name magic at 
all, and also keeps subdirectory structure intact. It only ensures that all 
images are present in the needed format for the chosen LaTeX flavour.

If you export to DVI then it assumes that you do not want to move a complete 
directpry structure around when you copy the DVI to some other location. 
Therefore it puts all files into one directory and needs tro make the names 
unique.


Georg

Re: trouble submitting IEEE conference article

[Georg Baum]

Neal Becker wrote:

> Thanks!  It does appear to work to export to DVI (LuaTeX) _after_ I
> uncheck Document/settings/fonts use non-tex fonts.

You mean after you uncheck or after you check the button? It is supposed to 
work like this:

use non-tex fonts checked => DVI (LuaTeX) works, DVI does not work
use non-tex fonts unchecked => DVI works, DVI (LuaTeX) might work

I believe that the error handling in this area has been improved in the 
upcoming LyX 2.2.

> Yes, good EPS were created.  Unfortunately, the names of the EPS files
> were mangled, and I think those names don't match those in the DVI file,
> so I needed to manually create a bunch of symlinks from the names used in
> the dvi file to the mangled names, e.g.,
> 
> 0_home_nbecker_scma-unframed_frame_format-cropped.eps -> frame_format-
> cropped.eps
> 
> The whole process would've been automated nicely if not for this.

The files are referenced using the mangled names in the DVI (at least on my 
machine). If the DVI does not reference the mangled files then this would be 
a bug => please report at http://www.lyx.org/trac/wiki/BugTrackerHome in 
that case.

If you want a DVI which refernces images without mangled names you need to 
produce it manually: Export to "LaTeX (plain)", which will produce a .tex 
file + all .eps files (unmangled). Then run latex, bibtex and other aux 
programs as needed to produce the DVI.


Georg

Re: trouble submitting IEEE conference article

[Georg Baum]

Neal Becker wrote:

> I'm submitting to IEEE VTC 2016 spring.  Article (written with LyX) is
> accepted (yay).

Congrats!

> 
http://www.ieee.org/conferences_events/conferences/publishing/vtc16spr.html
> says they only accept .dvi, and graphics in .eps, and they want to make
> the
> pdf.  I'm shocked, this is ancient obsolete tech.
>
> So I tried to follow this route, and uploaded a dvi and all graphics
> converted to eps, using pdftops -> pdf2epsi.  No doubt this will hurt the
> quality.

I would recommend to use LyX to do all these conversions. Exporting to DVI 
in LyX should produce the DVI file along with all needed .eps images. LyX 
does also know how to produce .eps images without quality loss (it uses 
pdftops with some flags, look at the "PDF (Graphics)" => EPS converter). 
Does viewing the DVI in LyX work?

> But conversion fails, I receive an email just saying
> The DVI source file you uploaded as a submission to the File Submission
> site failed to produce a postscript file.
> 
> If I try locally, I get:
> dvipdf ascma-paper.dvi ascma-paper.junk.pdf
> kpathsea:make_tex: Invalid fontname `"file:lmroman17-regular:script=latn;
> +trep;+tlig;"', contains '"'
> dvips: Font "file:lmroman17-regular:script=latn;+trep;+tlig;" not found;
> using cmr10
> dvips: Design size mismatch in font "file:lmroman17-regular:script=latn;
> +trep;+tlig;"
> dvips: ! invalid char 8211 from font "file:lmroman17-regular:script=latn;
> +trep;+tlig;"
> 
> Any ideas here?  I'm emailing them to see what can be done, but maybe you
> guys have suggestions?

Since they want to produce PS I would concentrate on the DVI => PS route, 
not DVI => PDF. You can narrow down the problem by previewing DVI or 
Postscript (or "PDF (dvipdfm)" if you want to stick to pdf). If this works, 
then something goes wrong with your conversion procedure. If it does not, 
then either the IEEE class needs some stuff you do not have installed, or 
something is wrong with your document.


Georg

Re: Aliasing, xyling, ps2pdf

[Georg Baum]

Guenter Milde wrote:

> If this is true, LyX configuration should choose "pdftops" if both tools
> are installed.
> 
> However, on my system this seems not to be the case:
> 
> * I have both, pdf2ps and pdftops (via package dependencies)
> 
> * still, the LyX-determined converter for 2.2dev is
>   pdf2ps $$i $$o
>   
> Can someone confirm/refute this finding?

Yes, the detection order in lib/configure.py is wrong.

> Should I file a bug report?

You couldd as well fix it directly in configure.py.


Georg

Re: Nomenclature prints 'Seite' instead of 'page'

[Georg Baum]

Guenter Milde wrote:

> It is "Tools>Preferences>Language Settings>Language>Set languages
> globally" which controls whether the language options are passed as
> global options to the document or directly to babel.

Sorry, I was too tired yesterday, and did not recognize the text in my 
german UI.

> Generally, it is good to have the options globally, so that other packages
> can pick this up.
> 
> In this document, however, the indexing is confused somehow to use one of
> the secondary languages (given before "english").

Yes. It is a bug in nomencl.sty: It does not process global language options 
in the same (unintuitive) order as babel. The first language wins for 
nomencl.sty. I fear there is not much LyX can do, except looking for a 
better alternative for nomencl (it seems to be unmaintained).

> Maybe we need a document specific setting for this.
> (But see also my other post exploring the issue.)

I think so. In general, any lyxrc setting that changes how documents are 
exported to .tex is bad IMHO, since this makes documents depend on the 
installation. The lyxrc setting should be replacved by a document specific 
setting, and the default for this setting would then be determined by the 
template for new documents.


Georg

Re: Aliasing, xyling, ps2pdf

[Georg Baum]

Maria Gouskova wrote:

> On Wed, Jan 6, 2016 at 5:14 PM, Georg Baum
>  wrote:
>> Maria Gouskova wrote:
>>
>>> This is Mac OS 10.8.5, LyX 2.1.4. I suspect I need to define a
>>> converter in Preferences/File handling, but am not having much luck
>>> finding the answer anywhere.
>>
>> Correct. If pdftops is in the path, then LyX should automatically define
>> a converter
>>
>> pdftops -eps -f 1 -l 1 $$i $$o
>>
>> for conversion from PDF (Graphics) to EPS. This one works fine for me
>> with your test file. Which converter do you have configured for PDF
>> (Graphics) to EPS conversion?
>>
> 
> I didn't have one defined by default for PDF(graphics) at all. When I
> added a PDF(graphics) to EPS converter, it defaulted to:
> 
> python -tt $$s/lyx2lyx/lyx2lyx -c big5 $$i > $$o
> 
> Which still produces an aliased PDF.
> 
> I tried defining it your way, but it seems that pdftops is not
> available on my setup. LyX throws up a non-specific error.

Then you need to install pdftops and either put the executable in a 
directory which is listed in the PATH environment variable, or define the 
converter using the absolute path to the installed pdftops (e.g. if the 
executable is located in /opt/xpdf/bin/pdftops, the converter would read

/opt/xpdf/bin/pdftops -eps -f 1 -l 1 $$i $$o

). You can download a binary from http://www.foolabs.com/xpdf/download.html, 
but since I am not a Mac expert I do not know if there are better ways to 
install it.

> I can't debug this properly since I am away from my other machine,
> which has Mac OS 10.9x and (as far as I recall) does not have this
> problem. Could be a MacTeX version difference? Or just OS-specific?

Probably not MaCTeX speicfic. My guess would be that on the other machine 
either pdftops or ps2eps (from ghostscript) is installed and found by LyX. 
BTW, pdftops is better than pdf2ps according to 
http://stefaanlippens.net/pdf2ps_vs_pdftops and also my own experience.


Georg

Re: Aliasing, xyling, ps2pdf

[Georg Baum]

Maria Gouskova wrote:

> This is Mac OS 10.8.5, LyX 2.1.4. I suspect I need to define a
> converter in Preferences/File handling, but am not having much luck
> finding the answer anywhere.

Correct. If pdftops is in the path, then LyX should automatically define a 
converter

pdftops -eps -f 1 -l 1 $$i $$o

for conversion from PDF (Graphics) to EPS. This one works fine for me with 
your test file. Which converter do you have configured for PDF (Graphics) to 
EPS conversion?


Georg

Re: Nomenclature prints 'Seite' instead of 'page'

[Georg Baum]

Michael Berger wrote:

> Hi Wolfgang, Robert, Kornel,
> thanks for your contributions.
> I just want to inform that in my case only one thing produces correct
> results and that is deactivating the global language settings. Here it
> does not matter whether or not the blue underlines are there or not.

What does "deactivating global language settings" mean? I am not aware of 
any global language setting that can be activated or decativated. Please 
tell us exactly which setting you change in Deocument->Settings->Language 
(or in Tools->Preferences)


Georg

Re: Render inkscape text with latex

[Georg Baum]

Rajil Saraswat wrote:

> Hello,
> 
> I want the text used in svg images to be rendered using latex.
> Inkscape provides instructions at
> http://wiki.inkscape.org/wiki/index.php/LaTeX on how to do this with
> Lyx. However this uses ERT and one loses the capability of seeing
> previews within Lyx.
> 
> Is it possible to modify the SVG convertor with lyx to automatically
> carry out the steps given on the inkscape wiki mentioned above?

Yes. LyX has so-called external templates, they are documented in the 
Customization Manual. Unfortunately they are not so easy to understand if 
one is not used to theem, but there is already a template which does the 
equivalent of what you want for Xfig figures.

You can define an inkscape template without modifying the LyX source code. 
If you do, it would be nice if you could contribute it. If you do not want 
to have ago yourself, please file an enhancement request at 
http://www.lyx.org/trac/wiki/BugTrackerHome (if none exists alreeady).


Georg

Re: Display SVG graphics in Lyx

[Georg Baum]

Rainer M Krug wrote:

> So this is a bug in qt (Linux (QT version ?) and OS X (Qt 4 version:
> 4.8.6)) - I have no idea about qt and it would not be possible for me to
> provide a bug report in a useful way.

I can confirm the bug with qt 4.8.6 and 5.3.2 on linux.

In order to report a qt bug it would be needed to write a small reproducer 
(starting from the code in src/frontends/qt4/GuiImage.cpp). As a preparation 
for that it would be nice if somebody could report it at 
http://www.lyx.org/trac/wiki/BugTrackerHome first (including the test case), 
then a LyX developer might report the qt problem later.


Georg

Re: Display SVG graphics in Lyx

[Georg Baum]

Rainer M Krug wrote:

> Hm - the output now works, but the preview still does not work. Which
> toolchain is actually used to create the preview?

Qt is used directly to display images in a number of formats, including svg. 
Therefore it would be a qt bug if the preview of an svg image is not 
displayed correctly.


Georg

Re: emf conversion on mac

[Georg Baum]

Rainer M Krug wrote:

> You have two options:
> 
> 1) use e.g. Irfanview (http://www.irfanview.com) in wine / PlayOnMac
>(https://www.playonmac.com/) to convert the images to a different
>format. Irfan view works very nicely on a mac.
> 
> 2) if you find a commandline tool for Mac (I didn't find one - please
>keep us posted if you find one) and define your own copier in LyX to
>convert the emf files.

3) Use our own metafile2eps with wine as documented in 
http://wiki.lyx.org/Windows/MetafileToEPSConverter. LyX will do eps->pdf 
automatically. The documentation is for linux, but I see no reason why it 
should not be applicable to OS X as well.

4) Find out how to use libreoffice on the command line to convert from emf 
to eps or pdf: libreoffice can read emf files even on non-windows platforms, 
and it is scriptable, so this should be possible in theory, but I have no 
idea whether it really works.


Georg

Re: Lyx to Latex to Lyx

[Georg Baum]

Hal Kierstead wrote:

> First of all, tex2lyx already comes close to making a good LyX file.  The
> main problem is that there always seem to be a handful or errors that must
> be fixed before the file will run.  For some reason the program cannot
> handle options like \begin{thm}[Main Lemma], but also other options.  It
> also seems that comments in the Latex file can sometimes produce errors. 

Please report bugs for these errors at 
http://www.lyx.org/trac/wiki/BugTrackerHome and include an example .tex file 
that shows the bug. These problems are sometimes easy to fix, the only thing 
we need is to be aware of them and a test case.

> A huge annoyance is that theorems, etc. are displayed in ERT.

The problem with theorems is that they are only recognized if the preamble 
is the same that would be used by LyX. Otherwise it cannot be guaranteed 
that the PDF output will be the same as in the original document. If the 
origional .tex file was produced by LyX, and your co-author did not define a 
new theorem style, but only changed an existing theorem or added a new one, 
then the theorems should be imported correctrly by tex2lyx. If this is not 
the case then please file  bug report.

> I understand that for arbitrary LaTex files some of these issues maybe
> very complicated or impossible, but what I am asking for does not involve
> arbitrary files.  Let’s take an easy case.  Suppose my coauthor only makes
> changes between \begin{document} and \end{document} of the LaTex file, and
> does not use any new constructs.  Shouldn’t it be possible, perhaps with a
> helper file that records settings and any other special issues, to make a
> good LyX version?  Or even easier, shouldn’t I be able to export a Latex
> file and then without changing it, import it and get the same LyX file
> back.  Yes, I know there is no reason to do this, but it is a benchmark.

Yes, this should be possible (with one limitation): There are some 
constructs in LyX that cannot be expressed in LaTeX or are not exported 
(e.g. Notes). We discussed in the past how to get rid of this limitation, 
but, but we do not have a consensus on a good soluition yet. Again, if have 
documents that do not re-import correctly, please file a bug.


Georg

Re: automatically updating latex code used in a LyX document

[Georg Baum]

Liviu Andronic wrote:

> On Fri, Jul 10, 2015 at 11:23 AM, José Matos  wrote:
>> On Thursday 09 July 2015 23:19:07 Liviu Andronic wrote:
>>> Perhaps we should consider renaming it to something like: "Child
>>> Document (TeX or LyX)"?
>>>
>>> Liviu
>>
>> Note that a child document can also be a programming listings or any
>> other file to be included verbatim. :-)
>>
> Absolutely, yet our naming is so terse so as to prove confusing.

Yes, it is confusing. The reason why the menu items are as they are is the 
implementation in three different insets: Include inset, graphics inset and 
external inset. However the functionality of those insets overlaps, and 
there is a very old plan to get rid of the graphics inset in favour of the 
external inset. We need some volunteers;-)

> Maybe
> we need a tooltip there, or a status message appearing when hovering
> the item, or something else. Otherwise people simply won't really know
> what that item is supposed to do, or worse assume that LyX is unable
> to do this at all (when it does!). I know RTFM would be one way to
> approach this, but maybe there is something we can do to ease
> confusion... Say, and yet another shot in the dark: "Include Child
> Document (.tex, .lyx, etc.)"

I guess it should be possible to rework the menu items independently of the 
insets, but I hjave no good idea myself.


Georg

Re: automatically updating latex code used in a LyX document

[Georg Baum]

Liviu Andronic wrote:

> On Thu, Jul 9, 2015 at 10:11 PM, Georg Baum
>  wrote:
>> Ian wrote:
>>
>>> Thanks Liviu. Inserting a Child document .tex file was exactly what I
>>> wanted to do. I just didn't know what it was called.
>>
>> Except for the fact that it is not automatically updated if the STATA
>> file changes.
>>
> If the content of the child .tex file changes, doesn't LyX
> automatically reflect those changes when recompiling the LyX document?

Yes it does. However, LyX does not recognize that the .tex file itself needs 
to be regenerated when the STATA file changes. The latter would be possible 
with an external inset.


Georg

Re: automatically updating latex code used in a LyX document

[Georg Baum]

Benedict Holland wrote:

> If you have generated the tex file in Stata, use ERT. It is much easier.

I am curious: What is easier if you include the file via ERT than with a 
child document? Note that I do not mean to convert the child document to LyX 
format, since LyX also allows to include child documents in LaTeX format.

> The command you want to look up is \input as in \input{table.tex}. This is
> the only way I generate, edit, and include tables now. This should also be
> the command that lyx uses... either that or include but I assume input
> would be a better use in this situation. I also use another application to
> edit the .tex because I need spell checking.

If you insert the .tex file as a child document you can do this as well: The 
child inset context menu provides an edit entry which fires up the .tex file 
in your favourite editor. I cannot imagine any easier way to reference child 
document in LaTeX format.


Georg

Re: automatically updating latex code used in a LyX document

[Georg Baum]

Ian wrote:

> Thanks Liviu. Inserting a Child document .tex file was exactly what I
> wanted to do. I just didn't know what it was called.

Except for the fact that it is not automatically updated if the STATA file 
changes.


Georg

Re: automatically updating latex code used in a LyX document

[Georg Baum]

Steve Litt wrote:

> On Wed, 8 Jul 2015 06:24:52 + (UTC)
> Ian  wrote:
> 
>> Hi
>> 
>> I want to automatically update latex code embedded in a LyX document
>> that was produced as output from another program, in my case STATA.
>> The Latex code contains table commands.
>> 
>> The concept is similar to handling graphics in LyX: Insert >> Graphic
>> >> (attach file). If I change the graphic file content, keeping the
>> >> file name
>> and location the same, the graphic image will automatically update in
>> LyX. I want to do the same thing, but with a .tex file in which
>> contains the Latex code for a table produced by STATA. The .tex file
>> name and location remain constant, but the content changes.
>> 
>> I am sure this is an easy thing, but I just can't seem to find it on
>> the web forums.

This is possible: LyX has a mechanism called "external templates" which can 
be seen as a generalization of the graphics inset: With an external 
template, you can tell LyX what it needs to do to convert your STATA file 
into LaTeX, and you also tell it how this LaTeX is to be included in the LyX 
document. The only requirement for this to work is that your application (or 
any other tool) allows to convert to LaTeX from the command line.

If you want to use this feature, you need to do two things:

1) Define a new external template for STATA as explained in chapter 6 "6 
Including External Material" in the Customization Manual. This neds to be 
once, and if you need help don't hesitate to ask on the list.

2) Each time you want to include  a STATA output, you use Insert -> File -> 
External Material.


> I do that kind of stuff all the time. The trick is to put some kind of
> an unmistakable token in your LyX doc. Then make a shellscript that
> cats your LyX into a script (I'd probably use AWK, your mileage may
> vary) to replace the token with the desired LaTeX, and then redirect
> the script's output to another LyX file. LyX --export latex
> tempfile.lyx;pdflatex tempfile.tex.

This is certainly technically interesting, but I would not recommend such a 
procedure to the original poster, since the builtin mechanism does not need 
those helper scripts, and all the export/view buttons in LyX do just work.


Georg

Re: Suggestion to improve Lyx for LaTEX users

[Georg Baum]

Liviu Andronic wrote:

> On Wed, Jun 10, 2015 at 2:34 PM, Richard Heck  wrote:
> 
>> my case). I wonder if just having the option of opening an ERT itself in
>> an external
>> editor would help?
>>
> As it happens, this is the subject of:
> http://www.lyx.org/trac/ticket/7404
> 
> Georg even provided a patch, and I suspect it requires not much
> programming to polish up that patch for inclusion.

Indeed, at least a a part of the requested feature should be easy to 
integrate. However, I still don't have enough time, so if anybody wants to 
chime in it would be most welcome (and of course I'll happily answer any 
question).

>> I suppose it might be an option to run tex2lyx on
>> whatever we get,
>> and replace the ERT inset with the result, in so far as that is possible.
>> I.e., we'd have
>> a sort of generic ERT-->LyX routine.
>>
> I think this would be a nice touch, indeed.

Should already work: Copy ERT, then Edit->Paste special->from LaTeX, then 
delete ERT. I guess you could even bind a command sequence to a custom key 
shortcut, so that you can type LaTeX, and having it interpreted by a single 
key combination.


Georg

Re: Strategies for locating errors

[Georg Baum]

Will Furnass wrote:

> On 5 May 2015 at 21:38, Georg Baum  wrote:
> 
>>
>> If you select the error item in the error dialog then the corresponding
>> LyX contents should should be selected in the main area as well. This is
>> not always 100% correct, but usually the error cause is nearby. Does this
>> not work in your case?
>>
> 
> Ah, I hadn't noticed that before!  That works perfectly if the error is in
> the master document but not if the error is in a child document (of which
> I have quite a few).
> 
> If would be great if LyX would switch to/open the child document
> containing the likely location of the error and move the cursor to that
> location.

I agree. Please file an enhancement request at 
http://www.lyx.org/trac/wiki/BugTrackerHome. It should not be too difficult 
to implement, since LyX has all information which is needed (which file and 
which line number). I guess it was simply forgotten.


Georg

Re: Strategies for locating errors

[Georg Baum]

Will Furnass wrote:

> How do others locate compilation errors in large multi-file documents?
> 
> I get a 'Missing } inserted' error for 'l.1052' when compiling but can't
> relate that line number to the LyX source.  I then try exporting to tex
> using pdflatex into a temporary directory and search through all 16 tex
> files looking for errors on or near line 1052.

If you select the error item in the error dialog then the corresponding LyX 
contents should should be selected in the main area as well. This is not 
always 100% correct, but usually the error cause is nearby. Does this not 
work in your case?


Georg

Re: Strategies for locating errors

[Georg Baum]

Wolfgang Engelmann wrote:

> That was the reason I was asking a while ago, whether the latex source
> panel (under >view) could show the tex line number. But I was told it is
> not possible under lyx.

Why that? Of course it would only be possible if the panel is set to show 
the full source (otherwise the line number would be wrong), but in that case 
it should not be a problem.



Georg

Re: xtended arrows

[Georg Baum]

Elbert Branscomb wrote:

> Hello,
> 
> I'm running lyx-2.1.3 on a 64 bit Linux box (Gentoo; up to date; except
> that the kernel is 3.12.13-gentoo).
> 
> With all lyx-provided math packages set to "load always", including
> specifically amsmath and mathtools  (and with lyx restarted) I still
> only have access to two of the extended horizontal arrows: xleftarrow
> and xrightarrow; not to any of the others listed in the math help
> document; most importantly for me at the moment: "xrightleftharpoons".
> This seems to contradict what the math help doc says in section 6.1.
> 
> Help?

The documentation is a bit terse here. The commands are not available in the 
sense "known by LyX", i.e. recognized as symbols or appearing in a menu or 
toolbar, but available in the sense "known by LaTeX", i.e. if you enter them 
as ERT in a math box, then the PDF output will be correct. This works for me 
(I suppose you know that \xrightleftharpoons needs an argument).

Not that you do not need to restart LyX (this is a document setting), and 
you only need to set mathtools to "load always", amsmath can be left at 
auto.


If you like, you can file enhancement requests at 
http://www.lyx.org/trac/wiki/BugTrackerHome for

a) the documentation (it should make it clear that ERT is needed)

and

b) native support for the not yet supported macros from mathtools.sty.


If you do not get a correct PDF output you can also file a bug report, but 
please include a minimal test case, otherwise it will be likely to be closed 
as "worksforme".


Georg

Re: Re: esint.sty in RedHat/Centos 7. Where? Why omitted?

[Georg Baum]

Paul Johnson wrote:

> I believe this may not be entirely necessary, however.  The esint
> package is not truly required to compile an elementary document.
> However, inside LyX, there is a switch under document / settings that
> says use esint automatically. I think that doesn't work properly, it
> tries to use esint even on an
> ordinary integral.  If we change esint to "do not load" then the basic
> document compiles.

I believe that esint is only loaded when it is needed. Please note that some 
integrals compile without esint, but they do look differently. esint fixes 
some inconsistencies, see http://www.lyx.org/trac/ticket/1942 for details. 
Please file a bug if esint is loaded in cases where it is not needed, i.e. 
the document compiles and does not produce inconsistent integrals without 
loading esint.


Georg

Re: esint.sty in RedHat/Centos 7. Where? Why omitted?

[Georg Baum]

Paul Johnson wrote:

> I searched long enough to see there is some peculiar history with
> packaging of esint.sty. I DO find the Fedora package in rpmfind.net
> "texlive-esint-...".  I will rebuild that on the EL7 systems if I have
> to. But I can't see why this is necessary at all.

I don't know why esint.sty is not properly packaged for Red Hat, but I would 
recommend to use vanilla texlive, and not the one provided by the 
distribution. Since texlive contains an own package manager for quite some 
time this is easy to do.


Georg

Re: \biggg not working

[Georg Baum]

Richard Heck wrote:

> On 03/04/2015 04:07 PM, Georg Baum wrote:
>>
>> The idea is simply to give a better display for those users who use these
>> packages. AFAIK these commands do not occur in any toolbar, menu or
>> autocompletion (and if they would this would be a bug).
> 
> That is a bit confusing for the user. Is there anything we can do?

Yes, it can be confusing. I think we have two options:

1) remove these macros from autocompletion
2) comment them in lib/symbols

I have no string preference. Which version do you prefer?


Georg

Re: \biggg not working

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Is \biggg even supposed to exist? I see that LyX code pretends to
> support it, but I do not understand how.
> 
> In lib/symbols, I see:
> 
> # The following are not standard LaTeX, but defined in the lucida font
> # packages. No 'm' versions!
> # See lucidabr.dtx for a possible implementation if you want to use these
> # with other fonts.
> biggg big none
> biggglbig none
> bigggrbig none
> Biggg big none
> Biggglbig none
> Bigggrbig none
> 
> 
> Georg, this is your code. Do you remember what the reasoning was?

There are several commands in lib/symbols which do not work without user 
preamble code. They are there because mathed can easily display these 
symbols, and they do not load the required packages automatically since they 
would have side effects.

The idea is simply to give a better display for those users who use these 
packages. AFAIK these commands do not occur in any toolbar, menu or 
autocompletion (and if they would this would be a bug).


Georg

Re: Lyx winbuilds

[Georg Baum]

Hi Peter,

this is intersting, but I think it is better suited for the development 
list.


Peter Johansson wrote:

> Only issues you can see as automake failed to analyze my latest version of
> magic and I had to add the common win libs manually, in this, my first
> "Lyx build run" containing three interrupts, made those directly in the
> makefiles.

If libmagic was not installed in an unusual location please tell us about 
the needed settings, so that we can improve the configure logic.

> The only issue with this particular Lyx build was that I had to install a
> MSVC poisoned python. One positive development for Lyx, would be to
> abandon python setups and deploy QT setting dialogs as of Texmaker and
> Texstudio.

What means MSVC poisoned python, and why was it needed? I don't think the 
the use of python in LyX will be abandoned in the forseeable future, since 
it is used for much more than just settings.

> Well it's quite simple as I've chosen all work computerss not operated by
> me personally to be UX ones.
> 
> But still, why not scrap MSVC altogether on Winbox distros ??.

The main reason is that our main windows developer uses MSVC. Apart from 
that we recently discovered also a technical problem with gcc:
The std::string implementation of GNU libstdc++ which comes with gcc is not 
C++11 conformant, and there are no plans to fix this (see 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334). The std::string 
implementation which ships with MSVC is C++11-conformant. You might think 
that this is a theoretical issue onl, but it caused a real bug which was 
very hard to track down: http://www.lyx.org/trac/ticket/9336.

>  gcc is under revolutionary development due to it's deployment on android
>  and most of todays supercomputers.

I get a different impression: gcc development stalls, the most interesting 
compiler developments currently happen in llvm. Anyway, LyX users should be 
free to choose the compiler which suits them most, so any changes to improve  
compilation with mingw are welcome.

> Many thanks for the great src package to all of you developers, donations
> will be due if Lyx becomes productively deployed on any project associated
> to me.

You are welcome.


Georg

Re: Unsupported math environments

[Georg Baum]

Rudi Gaelzer wrote:

> What I want and need is a means to implement the math ENVIRONMENTS defined
> by the mathtools package and that are not explicitly supported by LyX.
> Specifically for multiline equations.  LyX supports the standard AMS inner
> and outer environments, such as align (outer) and aligned (inner). 
> However, multline is only an outer env in the standard AMSmath.  The
> mathtools pack defines the corresponding inner multlined environment, and
> it seems that there is no way to use it other than ERTing the math input
> (see attached file). I guess the same tweak can be applied in order to use
> the other new environments defined by mathtools, such as dcases, rcases,
> drcases, psmallmatrix, bsmallmatrix, etc.

Unfortunately it is not possible to use unsupported math environments in LyX 
without putting the whole formula in ERT or do some advanced macro tricks. 
The reason for this is that the native LyX format for math formulas is 
LaTeX. This is implemented in such a way that _everything_ is parsed, so it 
is not possible to have a true ERT in mathed. The parser supports unknown 
commands somewhat (so they appear in red), but not environments.

This is of course a problem and needs to be fixed, but up to now nobody 
worked on it. If it does not exist already please file a bug report at 
http://www.lyx.org/trac/wiki/BugTrackerHome to support unknown environments 
in math.


Georg

Re: Korean Input Problem in tex Code mode on lyx 2.1.0

[Georg Baum]

Scott Kostyshak wrote:

> On Tue, Jun 17, 2014 at 8:55 AM, Seunghee  wrote:
>>
>> Hi, Scott,
>> thank you for your reply.
>> I have installed lyx2.2dev and tried to input Korean in the both of
>> modes.
>>
>> In the 'Program Listing' mode the problem is fixed, but not in the 'tex
>> mode'.
>>
>> I have found a difference between the both of modes.
>> Wenn I input alphabets in the 'program Listing' mode, the following
>> message appears:
>> "Font: Typewriter, text, Language: LaTeX"
>>
>> But in the 'tex mode'the following message appears:
>> "Font: Typewriter, LaTex text, Language: LaTeX"
> 
> Georg, do you know what's going on here?

Yes. The behaviour is by design. The explanation of the reason is a bit 
technical: Since version 1.5.0 LyX uses unicode internally, and .lyx files 
are encoded in utf-8. The big advantage of that compared to previous 
versions is that LyX can process and display text in almost all languages on 
earth. However, when LyX exports the document in LaTeX format for 
typesetting production, the situation is much more complicated. There are 
the modern LaTeX compilers like XeLaTeX and LuaLaTeX, which (like LyX) use 
unicode natively and take utf8-encoded input files, and there is the 
traditional LaTeX compiler which uses an 8-bit encoding internally and takes 
input files in different encodings, or even using multiple encodings in one 
file.

The difference between 'Program Listing' and 'tex mode' is the following: 
'Program Listing' is typeset using the listings LaTeX package, and that 
package supports a variety of different encodings. Therefore, when a 
'Program Listing' is output, LyX tries to find a suitable encoding which is 
supported by the listings package, and then converts the contents of the 
'Program Listing' into that encoding. This works usually. However, 'tex 
mode' means that the contents of the ERT inset is output 1:1, no 
transformation is allowed by definition (otherwise it would not be raw TeX 
anymore). This means that the contents must either be encodable in the 
currently active output encoding, or output would fail. Unfortunately, due 
to an internal limitation, we don't know the currently active output 
encoding where we need to know it (for LyX developers: latex_language-
>encoding() returns a static encoding, this needs to be dynamic and depend 
on the current environment). I want to change that in the long term, but 
this is the current situation.

Since you can get an uncodable document so easily with ERT insets, bug 9012 
was filed, and we fixed it by disallowing non-ASCII characters in ERT 
insets. Before the long term solution is implemented, we have two options: 
Reverting the fix for bug 9012, and live with the easy way to create 
uncodable documents, or do nothing and live with the fact that non-ASCII 
stuff does not work in ERT also in the cases when it would be encodable.

As a workaround for your problem, you can split your ERT inset in several 
parts, and put the korean text in standard mode.


Georg

Re: Embedding asymptote in Lyx

[Georg Baum]

Cyril wrote:

> The converter is from what initial format ? I guess the final is PDF.
> But the initial one is LaTeX, LyX,...?

That depends. I guess you want to use pdflatex for direct pdf production. In 
that case, use "LaTeX (pdflatex)" (code name pdflatex in the preferences 
file), and your three commands are

pdflatex myfile.tex
asy myfile-*
pdflatex myfile.tex

If you use TeXLive, you can even use latexmk instead of a wrapper script 
(from 
http://asymptote.sourceforge.net/doc/LaTeX-usage.html):

latexmk -pdf myfile

The final format is the new PDF variant you need to define. Otherwise your 
new converter would overwrite the default, and this would cause errors for 
files without asymptote code. 


Georg

Re: Embedding asymptote in Lyx

[Georg Baum]

Cyril wrote:

> Le 07/06/2014 04:52, Scott Kostyshak a écrit :
>>
>> I have little experience with this kind of thing, but you should take
>> a look at the converters section in Help > Customization. You could
>> create a format "pdfA" (or "PDF (Asymptote)" ) and then a converter
>> latex -> pdfA and add your commands there.
>>
>> Best,
>>
>> Scott
>>
>>
> Ty Scott,
> 
> That is eactly what I did, but the problem is "which commands ??".
> Since I have to execute 3 commands in just one converter. The
> documentation does'nt explain how to manage with this.

You need a wrapper script and define that one as converter. You can use the 
default converter shipped by LyX (scripts/convertDefault.py) as a template, 
and instead of calling convert, call your three commands in a row.


Georg

Re: Bug

[Georg Baum]

Patrick Dupre wrote:

>  unusual contents found: [Unknown [sub [mathrm [char N mathalpha][char O
>  mathalpha]] [char 2 mathalpha]]]

This means that LyX does not understand a math formula of that document. My 
first geuss would be that it has nothing to do with the OS our how you 
compiled LyX. This looks like a serious issue to me, which we need to 
investigate.

Could you please file a bug report at 
http://www.lyx.org/trac/wiki/BugTrackerHome and attach the document? If you 
can't publish it, you could also send it to me privately and I'll have a 
look, but without having the original document its is nearly impossible to 
investigate these kinds of bugs. If the document is really secret please do 
a bisection in with LyX 2.0.x and try to reduce it (removing first half of 
the document, seer if that fixes the problem, if yes continue with second 
half etc) until you find the formula which causes the problem.


Georg

Re: Lyx2.1 problem with metafile2eps converter

[Georg Baum]

aparsloe wrote:

> I was hasty in my response. In Adobe Reader X, under the Edit menu,
> there's the option Take a Snapshot. I assume this is the "embedded tool"
> referred to. When I copy a figure from the pdf and then go to paste it
> into LyX I get asked first to save the file, always as an .emf file
> although that can be changed to .png if I wish. The first one I paste
> into LyX reproduces the copied figure. Copying and pasting other figures
> (after saving in .emf format) generally insert into LyX  figures that
> are about 25 times too big. I have to scale to about 4% for the Adobe
> --> LyX --> Adobe round trip to reproduce a figure about the size of the
> original. But this doesn't happen always and seems to depend on whether
> I've saved a file at some point as .png (which seems to paste at the
> right size). So, it works for a one-off, but clearly not flawlessly for
> a number of copy-pastes.

Strange. We need somebody to debug LyX on windows.


Georg

Re: Lyx2.1 problem with metafile2eps converter

[Georg Baum]

aparsloe wrote:

> On 11/05/2014 8:31 a.m., didiergab...@free.fr wrote:
>> Hi,
>>
>> I have problem wth lyx2.1 (on windows 7 64bits)... I often copy images
>> from adobe reader with the embedded tool and paste directly on lyx
>> (ctrl+V)... I have a error message "Can not open Metafle to EPS converter
>> printer" (without "i" on "Metafle" :o)
>>
>> When I try the conversion directly from Lyx2.1 dir\bin\metafile2eps.exe
>> the same error occur... Any idea ?

Is the virtual printer installed which is used by metafile2eps.exe? Maybe 
something wnet wrong during installation.

> I've also got LyX2.1 on  64 bit Windows 7, and Adobe Reader X, and the
> copy and paste works without problems, so this looks like a problem at
> your end rather than with LyX.

Also for copying vector images? metafile2eps.exe is not used for bitmap 
images or text. You can easily see whether a vector imagtes was copied by 
looking at the type of the copied image: If it is eps, the original image 
was in vector format, and metafile2eps.exe worked.


Georg

Re: [GSoC 2014] Introduction

[Georg Baum]

Prannoy Pilligundla wrote:

> Hi Everyone,
> 
> I am Prannoy Pilligundla, a second year undergrad from India. I will be
> working on Roundtrip Conversion from Lyx to ODT throughout the Summer as a
> part of Google Summer of Code 2014. First of all I want to thank the
> community for keeping faith in my abilities and selecting my proposal, I
> will definitely put in my best efforts to complete this project. Also
> Congratulations to the Co-GSoCer Sushant Raikar, all the best to you too.

Welcome to both of you! I might not always be the quickest one to respond, 
but I'll try to help wherever needed.


Georg

Re: Using LyX for calculations (was Rendering of LyX's math screen fonts.)

[Georg Baum]

Jerry wrote:

> I know that LyX has hooks for some computer algebra systems (Mathematica,
> Maple, Maxima) and Octave. I have played with these a little (Octave and
> Mathematica) and it seems potentially useful but possibly not fully
> developed in LyX.

It is only very basic (and therefore not much advertised).

> I'm curious to know how you and others have used this corner of LyX.

I did not use this interface. I did manual calculations involving bigger 
equations that I would otherwise have done on paper. I used LyX only because 
I could easily incorporate corrections (and print the result again for final 
proof reading).


Georg

Re: Rendering of LyX's math screen fonts.

[Georg Baum]

Rudi Gaelzer wrote:

> So I ask you LyXperts: is it possible to configure the math mode editor so
> that it uses also mathabx and other different math fonts?  The roadmap to
> LyX 2.1 mentions enhanced support for math font selection (OpenType fonts)
> and support ofr cropped PDF/EPS.  However, AFAIU, these enhancements will
> have an effect on IP and on the exported document.  Seems to me that the
> math editor will still use the same screen fonts.  Or am I wrong?

You are right, the mentioned features do not affect the look of the math 
editor. However, there are some new symbols in 2.1, mainly from stmaryrd.sty 
and mathtools.sty. To some extent you can also add some on your own: The 
screen appearance of math symbols is defined in the file lib/symbols, which 
contains some very basic documentation for 2.1.
Basically, there are three kinds of symbol definitions in that file:

1) symbols supported by special insets (like the decorations)
2) symbols supported by fonts (like the ones from fontmath.ltx)
3) symbols without any builtin support

Adding symbols of type 1) and 2) requires some programming in LyX, and 2) 
requires also a true type font containing the symbols in a certain order, 
but symbols of type 3) can easily be added by users: All lines starting with 
\def are of this kind. For example, you could define \partialslash like 
this:

\def\partialslash{\partial\kern-12mu/}

The slash is a bit too short, but maybe there is a longer one already 
supported by mathed, which you could use instead. Although this looks like a 
TeX macro definition, it is not used for the output, only for display in 
LyX. There is basically no documentation how exactly this \def works, you 
have to use trial and error. You could also make the mathabx package load 
automatically if this symbol is used (works only for packages in the 
compiled in feature list of LyX, and mathabx is in there):

\def\partialslash{\partial\kern-12mu/} mathabx

I strongly advise against doing so, because this makes your LyX document 
depend on your personal installation, and it would not typeset on vanilla 
installations. This feature is rather for symbols distributed with the 
official symbols file.

Finally, if you want some symbols to appear officially in LyX, you could add 
them to bug , but please note that font changing packages like txfonts 
will not be used.


Georg


PS: It is funny that you also use the math editor for calculations. I used 
to do that a lot for my thesis, but always thought I was the only one.

Re: Pasting graphics in LyX 2.1 beta on Mac

[Georg Baum]

Anders Ekberg wrote:

> Thanks Patrick
> I think you are on to the reason (see my previous post sent just as I got
> your reply). But I don't see how to save as a pdf. In the beta1 the only
> options are png and jpeg and both give 72 dpi resolutions (setting the
> suffix as pdf results in a file that Preview can't open, but that works
> with low res in LyX; probably a png).

Patricks finding looks very reasonable to me as well. If PDF is not offered 
for pasting this means that LyX dos not see any PDF on the clipboard. If you 
call LyX with

lyx -dbg action

in a terminal and look for "Found format" you should see whether it finds 
PDF or not. If that does not give any new insight you'd need to run LyX in a 
debugger. The place to look at would be GuiClipboard::hasGraphicsContents().


Georg

Re: Pasting graphics in LyX 2.1 beta on Mac

[Georg Baum]

Anders Ekberg wrote:

>> I noticed when I had to paste some graphics with a lot of text that LyX 
>> (or
>> rather the libraries used by LyX) seem to reduce the resolution of the 
>> pasted
>> graphics (copied selection from Preview and pasted as a png-file in 
>> LyX). Anyone else experienced it, or could it be a setting somewhere in
>> my environment? If so, does anyone have an idea of how to solve it (save
>> the cropped file as a png in Preview of course works, but is several
>> additional steps).
>> 
>> All the best!
>> Anders
> The best you can do in these cases is save the graphic in svg format
> whenever posible. Otherwise you must edit your graphic on inkscape to add
> the text manually and then export it as svg. If you doesn´t go into
> vectorial graphics you will definetively lose resolution and then the text
> will look awful.

While I would always prefer svg over png if the source is a vector graphic, 
this does not help for bitmaps as the one Anders is trying to paste.

> Thanks Alex,
> I probably wasn't clear enough: The picture is scanned to pdf with 300 dpi
> resolution. When cropping and saving in Preview to a png with 300 dpi and
> then inserting this picture in LyX (with insert graphic) the output is
> fine (i.e. with a resolution of 300 dpi which is sufficient for my
> purposes). On the other hand when I copy in Preview and then paste in LyX,
> the resolution becomes low (I would guess about 150 dpi, which is
> incidentally the default resolution when saving png:s in Preview, so the
> problem well may be on the copying and not the pasting side).
> 
> So, in short, my question is: Which resolution does LyX use to save
> graphics (on Mac) and is there a way to change it?

LyX does not scale the graphics. It uses whatever is on the clipboard, but 
maybe there is some scaling happening in qt. Did you try to paste the 
graphics in a different application, e.g. gimp? If that does not preserve 
the resolution the problem is with copying the graphics to the clipboard. 
Otherwise it is in LyX or qt, and one would need to debug.

> I also tried on Windows (copying from Acrobat Reader) and there the
> resolution was good, but the dimensions distorted (compressed in height).

Strange. Does the distortion come from different x/y scaling factors in LyX, 
or is it also visible in the created .png file?


Georg

Re: Wrong language for theorems/lemma/other amsthm environments

[Georg Baum]

Damien Desfontaines wrote:

> Hello,
> 
> Following the advice given by scottksty in the following thread:
> http://tex.stackexchange.com/questions/116462/wrong-names-for-
theorems-lemma-etc-in-lyx
> I am sending a minimal example showing my problem, that is, the name
> of the AMS theorems layouts appear in french in the PDF files produced
> by LyX, even if the language of the document is set to english. I use
> LyX 2.0.3, my user interface is in french, but as you can see in the
> .lyx file, my document's language is english.
> 
> I also attached to this e-mail the .tex file generated by "Export" →
> "LaTeX (pdflatex)", which shows the problem: below the commentary line
> « Textclass specitif LaTeX commands », the thm environment is set with
> a french name:
> 
> \theoremstyle{plain}
> \newtheorem{thm}{Théorème}
> 
> The same thing happens for all other amsthm environments, except,
> strangely, for the proof environment.

This is not the code LyX 2.0.x produces. LyX produces


\theoremstyle{plain}
\newtheorem{thm}{\protect\theoremname}

\makeatother

\usepackage{babel}
\providecommand{\theoremname}{Theorem}


for a single language english document, and for a multi language document 
(english and french) it would additionaly write the following two lines:


  \addto\captionsenglish{\renewcommand{\theoremname}{Theorem}}
  \addto\captionsfrench{\renewcommand{\theoremname}{Théorème}}


Therefore, I guess that you used the translated layout files from 
wiki.lyx.org for 1.6.x (LyX only got native support for layout translations 
in the output with version 2.0.0), and that these layout files are still 
lying around and being used. I guess that the problem will go away if you 
rename ~/.lyx/layouts to ~/.lyx/layouts-tmp and reconfigure. If that helps, 
you can move those layouts back to ~/.lyx/layouts which you want to keep.

> I hope that I have described the problem clearly enough and that my
> example is minimal enough so that you do not waste your time on it.

It is a perfect minimal example, and since you also included the .tex output 
I am pretty sure that it helped to identify the real cause of the problem.


Georg

Re: install lyx 2.0.5-1 linux debian --- was: install lyx 2.0.3-3 linux debian

[Georg Baum]

Wolfgang Engelmann wrote:

> I am sorry that I can't help except perhaps with testing/writing the helps
> (the advantage would be, that I always manage to do the wrong things if
> the advices are not idiot-proof ...)

Testing and entering the results in 
http://www.lyx.org/trac/wiki/BugTrackerHome is always useful (also trying to 
reproduce existing bug reports if this was not yet done). If you want to 
help with documentation, please ask on the documentation list 
(http://www.lyx.org/MailingLists#toc5) which parts need work.


Georg

Re: install lyx 2.0.5-1 linux debian --- was: install lyx 2.0.3-3 linux debian

[Georg Baum]

Wolfgang Engelmann wrote:

> Am Dienstag, 5. März 2013, 17:10:56 schrieb David L. Johnson:
>> 
>> No, it gets the filename as an argument, and then generates the new
>> version.  You can actually read that off of the file lyx2lyx itself,
>> which is a script:   "usage: %prog [options] [file]".  Options are
>> things like --verbose, --quiet, --debug.  Unless you specify an output
>> by  the option "-o outputfilename" it will spit the output to stdout.
>> 
>> So, to process a file "oldfile.lyx" and get an updated version
>> "newfile.lyx", enter on the command line:
>> 
>> /full/path/to/lyx2lyx -o newfile.lyx oldfile.lyx

Caution: This converts to the latest version known by lyx2lyx. If you copy 
the 2.1 lyx2lyx into the 2.0 installation as suggested elsewhere (which 
works without further adjustments, and is probably the most easy way to deal 
with files in the new format), you always have to give the -t 413 arguments 
if you want to convert to 2.0.x format. Otherwise the command above would 
convert to format 464 (the current 2.1 format number).

> By the way, is there any idea when the 2.1 version will be official?

No. The development man power is very limited, and so far there is no 
release plan, although it seems to be consensus to stop with new features 
and concentrate on the release.


Georg

Re: install lyx 2.0.5-1 linux debian --- was: install lyx 2.0.3-3 linux debian

[Georg Baum]

Wolfgang Engelmann wrote:

> Now it works after following your advices. Two questions left:
> 
> 1-
>  former lyx 2.0.5-1 created lyx files which lyx 2.0.3-3 does not take:
> Blumenuhr-neu20120302.lyx stammt von einer neueren LyX-Version, aber das
> lyx2lyx-Skript konnte das Dokument nicht konvertieren

This should never happen. All 2.0.x versions use the same file format. If 
the header contains the line with LyX 2.1 mentioned by Scott then the file 
was probably opened at least once with LyX 2.1. Then you need to open it in 
2.1 again and export it to 2.0 format.

>  I understand, lyx2lyx could take care of it outside lyx, but
> bash: lyx2lyx: Kommando nicht gefunden
> do I have to get the prg from somewhere else or do I use it incorrectly (a
> py file?)
> 
> 2-
> I use texlive, do I have to give the path to it in the lyx file or
> additionally somewhere else?

No, the .lyx file does not contain paths to your TeX installation (on 
purpose). If the texlive binary directory is in the PATH environment 
variable it works.

Do you use squeeze (stable) or wheezy (testing)? I have .deb packages for 
the latter that are 100% drop in replacements of the debian 2.0.3 debs which 
I could share.


Georg

Re: Import Latex vs AMS Layout

[Georg Baum]

Richard Heck wrote:

> On 10/22/2012 10:16 AM, Rahayu wrote:
>> I enjoy working with LyX very much,
>> however I have to exchange .tex files with my colleagues,
>> because Latex is the common format for them.
>> So I export my work in LyX to .tex format, however when I get my
>> file back, and I need to import the .tex file to LyX again,
>> it doesn't recognize the Theorem and appear in
>> ERT or latex box, which is so inconvenient.
>>
>> Anyone could help please?
>>
> What version of LyX are you using? Can you post the simplest possible
> example file that causes this problem for you?

Not needed, this is bug http://www.lyx.org/trac/ticket/5702. He sent the 
same mail privately to me on october 23rd, and I already answered. If I had 
known that others got the same mail my answer would have been different.


Georg

Re: xfig and LyX

[Georg Baum]

Wolfgang Engelmann wrote:

> Could you tell me, whether this 'bring together both' is a task for xfig
> or for grafics/external material on the lyx side?


It is a LyX issue. xfig (or any other program) does not know (and should not 
need to know) about the internals of file inclusion of LyX.


Georg

Re: xfig and LyX

[Georg Baum]

Wolfgang Engelmann wrote:

> Am Dienstag, 23. Oktober 2012, 21:23:11 schrieb Georg Baum:
> 
> Thanks, Georg,
> 
> but I have still not managed to get the greek letter displayed in the .fig
> file in LyX. If you don't mind, I would like to send you a minimal lyx
> file and the fig file privately (together 10kb) for a trial. May I?

Sure, I can have a look. But I can't promise that I'll find the problem ;-)


Georg

Re: xfig and LyX

[Georg Baum]

Wolfgang Engelmann wrote:

> But I can't get it work.
> I am using Lyx 2.1.0
> and I have transfig installed which contains fig2dev
> 
> What I did:
> In xfig (3.2.5b):
> Text flags > special flag >special >set
> Text-font > use Postscript Fonts > use Latex font >
> jumps back to Fonts Menu
> #not sure what to select here

You need to do this before entering the text. Then it works for me. I don't 
know how to change these settings for existing text. It looks like they are 
some global settings that only influence newly created text.

> in the fig graphic I have a text with $\alpha$
> 
> In Lyx under
> - >tools>preferences>file handling
> converter definitions FIG>EPS
> ->converter fig2dev -L eps $$i $$o
> extra flag is empty and save apply is greyed out
> #not sure whether this is correct

You should not define anything related to xfig yourself here. If this 
converter is defined in your preferences file, please delete it from there. 
If it is in the syntax.default file (which is created by reconfigure) then 
it is fine.

> The fonts in Lyx I have selected are
> Roman -Palatino
> SanSerif Helvetia
> Typewriter ComputerModern

These should not matter.

> I have reconfigured Lyx
> 
> I insert the .fig file with
> -> File
> -> External material (Xfig's Template)
> and see the graphic with  $\alpha$
> 
> But the pdf file does not show the greek alpha, but still $\alpha$.
> 
> I am not sure what I do wrong. Is it on the xfig side or the lyx side?

Probably xfig.


Georg

Re: lyx osx find&replace window cannot be closed

[Georg Baum]

Am Thursday, 20. September 2012 schrieb axys:
> hallo georg baum!
> 
> bitte um verständnis, dass ich mich so direkt an dich wende - falls ich 
an der falschen adresse bin, bitte leite das email an jemand weiter, die 
oder der mir weiterhelfen kann oder vielleicht an das bug-report-system.
> 
> deutsch:
> LyX 2.0.4 unter Mac OS X
> Das Suchen & Ersetzen -Fenster läßt sich nicht schließen. Es ist zu weit 
oben am Bildschirm. Dadurch rutscht es hinter die OSX-Menüleiste und der 
rote Knopf zum Schliessen des Fensters ist von der OSX-Menüleiste verdeckt
> 
> version: 
> lyx 2.0.4
> os x 10.6.8
> 
> english:
> LyX 2.0.4 running on Mac OS X
> Find & Replace window cannot be closed because its place on the screen is 
too high up. so it slips behind the OS X menu bar whereby the red close-
window-button cannot be reached (it is hidden behind the menu bar)
> 
> thank you for doing all this great work!
> greetings from vienna,
> konrad.


Hi,

can somebody help this guy please? I have no idea why that happens.


Georg

Re: KOMA report and localisation problem.

[Georg Baum]

Pavel Sanda wrote:

> Georg,
> 
> would it be easy to add Listing into the layouttranslation machinery we
> automatically use on the LyX side?

Yes (see attachment). Two questions:

1) Why is features.useInsetLayout() not called for each inset in validate()?
2) Does anything break if I make InsetInclude::layoutName() return 
"Listings" for listing includes instead of the ugly hack in 
InsetInclude::validate()?

While testing I also noticed that LyX would sometimes overwrite the exported 
.tex without wraning, but I could not see a pattern. Is that known?


Georgdiff --git a/lib/doc/Customization.lyx b/lib/doc/Customization.lyx
index c3024df..f97cd15 100644
--- a/lib/doc/Customization.lyx
+++ b/lib/doc/Customization.lyx
@@ -14255,6 +14255,31 @@ InsetLayout
 \end_layout
 
 \begin_layout Description
+\change_inserted -195340706 1333913893
+\begin_inset Flex Code
+status collapsed
+
+\begin_layout Plain Layout
+BabelPreamble
+\end_layout
+
+\end_inset
+
+ Preamble for changing languages. See section
+\begin_inset space ~
+\end_inset
+
+
+\begin_inset CommandInset ref
+LatexCommand ref
+reference "sub:I18n"
+
+\end_inset
+
+.
+\end_layout
+
+\begin_layout Description
 \begin_inset Flex Code
 status collapsed
 
@@ -14904,6 +14929,34 @@ Branch
 \end_inset
 
 ) modify this label on the fly.
+
+\end_layout
+
+\begin_layout Description
+\change_inserted -195340706 1333913893
+\begin_inset Flex Code
+status collapsed
+
+\begin_layout Plain Layout
+
+LangPreamble
+\end_layout
+
+\end_inset
+
+ Language dependent preamble.  See section
+\begin_inset space ~
+\end_inset
+
+
+\begin_inset CommandInset ref
+LatexCommand ref
+reference "sub:I18n"
+
+\end_inset
+
+.
+
 \end_layout
 
 \begin_layout Description
diff --git a/lib/layouts/stdinsets.inc b/lib/layouts/stdinsets.inc
index 28a08ab..2213612 100644
--- a/lib/layouts/stdinsets.inc
+++ b/lib/layouts/stdinsets.inc
@@ -4,7 +4,7 @@
 #
 # Detailed format description is available in the customization manual
 
-Format 36
+Format 38
 
 Provides stdinsets 1
 
@@ -190,6 +190,9 @@ InsetLayout Listings
 	FreeSpacing   true
 	ForceLTR  true
 	RefPrefix lst
+	BabelPreamble
+		\addto\captions$$lang{\renewcommand{\lstlistingname}{_(Listing)}}
+	EndBabelPreamble
 End
 
 InsetLayout Branch
diff --git a/lib/layouttranslations b/lib/layouttranslations
index 2c9f81c..6174c81 100644
--- a/lib/layouttranslations
+++ b/lib/layouttranslations
@@ -30,6 +30,7 @@ Translation ar
 	"List of Graphs" "قائمة الرسوم البيانية"
 	"List of Schemes" "قائمة التصميمات"
 	"List of Tableaux" "قائمة الجداول"
+	"Listing" "عمل قوائم"
 	"Notation" "تدوين"
 	"Note" "ملاحظة"
 	"Problem" "مشكلة"
@@ -106,6 +107,7 @@ Translation ca
 	"List of Graphs" "List of Graphs"
 	"List of Schemes" "List of Schemes"
 	"List of Tableaux" "List of Tableaux"
+	"Listing" "Llistat"
 	"Notation" "Notació"
 	"Note" "Nota"
 	"Problem" "Problema"
@@ -145,6 +147,7 @@ Translation cs
 	"List of Graphs" "Seznam grafů"
 	"List of Schemes" "Seznam schémat"
 	"List of Tableaux" "Seznam tabel"
+	"Listing" "Výpis"
 	"Notation" "Značení"
 	"Note" "Poznámka"
 	"Problem" "Úloha"
@@ -184,6 +187,7 @@ Translation da
 	"List of Graphs" "Grafliste"
 	"List of Schemes" "Schemaliste"
 	"List of Tableaux" "Tableauliste"
+	"Listing" "Listing"
 	"Notation" "Notation"
 	"Note" "Notat"
 	"Problem" "Problem"
@@ -223,6 +227,7 @@ Translation de
 	"List of Graphs" "Liste der Graphen"
 	"List of Schemes" "Liste der Schemata"
 	"List of Tableaux" "Tableaux-Verzeichnis"
+	"Listing" "Listing"
 	"Notation" "Notation"
 	"Note" "Notiz"
 	"Problem" "Problem"
@@ -266,6 +271,7 @@ Translation el
 	"List of Graphs" "Λίστα Γραφημάτων"
 	"List of Schemes" "Λίστα Σχεδίων"
 	"List of Tableaux" "Λίστα Ταμπλό"
+	"Listing" "Καταλογοποίηση"
 	"Notation" "Σημειογραφία"
 	"Note" "Σημείωση"
 	"Problem" "Πρόβλημα"
@@ -305,6 +311,7 @@ Translation en
 	"List of Graphs" "List of Graphs"
 	"List of Schemes" "List of Schemes"
 	"List of Tableaux" "List of Tableaux"
+	"Listing" "Listing"
 	"Notation" "Notation"
 	"Note" "Note"
 	"Problem" "Problem"
@@ -344,6 +351,7 @@ Translation es
 	"List of Graphs" "Índice de gráficos"
 	"List of Schemes" "Índice de esquemas"
 	"List of Tableaux" "Índice de Tableaux"
+	"Listing" "Listado"
 	"Notation" "Notación"
 	"Note" "Nota"
 	"Problem" "Problema"
@@ -383,6 +391,7 @@ Translation eu
 	"List of Graphs" "Grafikoen zerrenda"
 	"List of Schemes" "Eskemen zerrenda"
 	"List of Tableaux" "Taulen zerrenda"
+	"Listing" "Zerrenda"
 	"Notation" "Notazioa"
 	"Note" "Ohar"
 	"Problem" "Buruketa"
@@ -422,6 +431,7 @@ Translation fi
 	"List of Graphs" "Kuvaajien luettelo"
 	"List of Schemes" "Kuvausten lettelo"
 	"List of Tableaux" "Taulujen luettelo"
+	"Listing" "Listaus"
 	"Notation" "Merkintätapa"
 	"Note" "Muistiinpano"
 	"Problem" "Ongelma"
@@ -461,6 +471,7 @@ Translation fr
 	

Re: lyx latex-import problem

[Georg Baum]

Ingar Pareliussen wrote:

> Hi
> 
> I have a couple of hundred abstracts from a web form that
> produces simple LaTeX files. I have cat'ed them into one big LaTeX file
> and imported it to LyX. This works for the most part, but I have
> problem with \sindex that needs a option i [index_name] which is not
> recognized by LyX and therefor not put into ERT.
> 
> I tried to get search replace it, but when LyX  search within ERT it uses
> all memory and even if it seems to do the right thing it has been working
> on the file for a couple of hours... (file is only 300k and the box has 4G
> of ram, so something seems to be amiss)

Please file a bug report if the file is not secret (or if you can easily 
create a non-secret one).

> Is there some advice on how to do this more efficient? I could do it
> manually, but automated is better :)

Yes. You have two options:

1) Add the line

\sindex[]{translate} %splitidx.sty

to the file lib/syntax.default in your LyX installation, and import the file 
again. This should produce correct ERT.

2) Get the current BRANCH_2_0_X from svn or wait for 2.0.4. This will create 
real index insets for \sindex.


Georg

Re: How to force tex2lyx to read unicode (from within Lyx)?

[Georg Baum]

Guenter Milde wrote:

> On 2012-02-15, Georg Baum wrote:
>> Jean-Marc Lasgouttes wrote:
> 
>>> Georg, Juergen, I'd like some feedback on the soundness of the patch. I
>>> know next to nil about xetex, and I do not know what is the current
>>> state of the art wrt tex2lyx.
> 
>> Unfortunately I know next to nothing about use_non_tex_fonts. After
>> reading the code and user guide a bit I see that using xetex is only
>> possible if use_non_tex_fonts is true, so your patch looks fine.
> 
> It is the other way round: using xetex or luatex is also possible without
> use_non_tex_fonts (which actually means use_fontspec). OTOH, with
> use_non_tex_fonts True, it one of xetex or luatex must be used.

For luatex I agree, but for xetex I don't believe that you are right. Do you 
have an example .lyx file, where use_non_tex_fonts is false, but xetex is 
still used? If you are right, the patch introduces a regression.


Georg

Re: How to force tex2lyx to read unicode (from within Lyx)?

[Georg Baum]

Jürgen Spitzmüller wrote:

> LuaTeX can use other encodings, but not with non-tex fonts. So if
> \use_non_tex_fonts is true (this is what you want to check for, right?),
> the encoding of the file must be utf8.

No, it is the other way round: If a xetex package is detected, 
use_non_tex_fonts is set to true, and the encoding is set to utf8.

> If other encodings are used, LuaTeX uses the "luainputenc" package, which
> has the same syntax than inputenc, i.e.
> 
> \usepackage[]{luainputenc}
> 
> Maybe we have to care about that.

luainputenc is already handled. What is missing for luatex is to set 
use_non_tex_fonts to true and the encoding to utf8 if luainputenc is not 
used. Unfortunately this is not so easy as with xetex.


Georg

Re: How to force tex2lyx to read unicode (from within Lyx)?

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Georg, Juergen, I'd like some feedback on the soundness of the patch. I
> know next to nil about xetex, and I do not know what is the current
> state of the art wrt tex2lyx.

Unfortunately I know next to nothing about use_non_tex_fonts. After reading 
the code and user guide a bit I see that using xetex is only possible if 
use_non_tex_fonts is true, so your patch looks fine.

Georg

Re: How to get full image filenames into LaTeX export?

[Georg Baum]

Guenter Milde wrote:

> 
> I just checked with 1.6.7 - indeed the extension is gone.

This is done on purpose. The reason for this is to make the exported LaTeX 
file as versatile as possible. This way, you can use the same .tex file with 
pdflatex and latex (unless you include other stuff that works with one 
version only), as long as you ensure that both .eps and .pdf/.png/.jpg 
versions of the images exist.

> I thought it was kept some time (maybe years) ago.
> 
> IMV it's worth a feature request as
> 
> * there are cases where the author is smarter than her/his computer,
> * it is easy to get the automatic selection by just leaving off the
> extension.

No, this does not work. LyX needs to know _exactly_ which image is the 
source. This was indeed different many years ago, but that lead to all sorts 
of problems, so I reworked it (ca. for 1.3 or 1.4).

If the default behaviour does not fit your special needs, you can always 
write an external template, as suggested already. Another option would be to 
write a copier for the latex format, which adds the extension for all 
\includegraphics commands. If you don't know hat a copier is, read 
Customization.lyx. The advantage of this solution is that it works with all 
documents, not just the ones that use a special template.


Georg

Re: Goodbye message and the search for a new LyX Debian package maintainer

[Georg Baum]

Sven Hoexter wrote:

> Hi all,
> I already switched my work focus away from things where LyX is involved
> (about half a year ago), but only recently settled for a new fulltime
> employment starting next week. So after about five years maintaining the
> LyX package in Debian together with Per this is kind of my goodbye message
> to all the marvelous people who helped me/us along the way.[+]

Hi Sven,

I am amazed that is was such a long time. Thank you very much for your 
effort, it surely has helped a lot of people. For me it was a pleasure to 
work together with you. I hope that we soon get a new maintaner who keeps up 
the good work.


Georg

Re: Translations of Math environments in LyX output - last call for LyX 2.0

[Georg Baum]

Jean-Pierre Chrétien wrote:

> I don't unserstand what happened, a lot of strings which are not
> translated in frenchb.ldf have disappeared.

Yes. This was done intentionally, because these strings are not needed for 
most languages. Note that you can readd these translations manually to 
lib/layouttranslations if needed, and they will stay in the future. I can't 
judge whether this is a good idea, but it is technically possible.


Georg

Re: Translations of Math environments in LyX output - last call for LyX 2.0

[Georg Baum]

Pavel Sanda wrote:

> Rudi Gaelzer wrote:
>> Dear Pavel.
>> Concerning the translation to brazilian portuguese, your structure works
>> with your template file (localization_test_1.lyx), which employs the
>> Theorems (AMS) and Theorems (AMS-Extended ) modules.
>> However, when I try the numbered by type modules, I detect the same
>> problems I already mentioned in my previous threads:
> 
> you attached wrong document, because its identical to the previous one...
> anyway i can reproduce your problem. it seems that our mechanism is not
> working for all AMS modules. Georg?

These styles are missing the LangPreamble and BabelPreamble tags, since they 
did not exist yet when those tags were introduced. Somebody should go 
through all modules that have been added after the initial translation 
support (Feb. 2009) and add these tags where it makes sense. Unfortunately I 
have no time do so ATM. Fortunately the mentioned theorems will most 
probably not produce new strings for lib/layouttranslations.


Georg

Re: Poll for the default icon theme in LyX 2.0

[Georg Baum]

libreoffice

Re: using "import" package within LyX?

[Georg Baum]

Jürgen Spitzmüller wrote:

> James C. Sutherland wrote:
>> Can't LyX sort through this issue in the same manner as it does with
>> graphics paths, i.e. by transforming relative paths to absolute paths
>> when the LaTeX is exported to the temporary directory?

It can do so if you instruct it how it should be done (using the so-called 
external templates). As others wrote it can not interpret ERT at all, and 
any attempt to do that would cause serious problems.

>> So behind the scenes,
>> LyX could change:
>>   \subimport{ relative path }
>> to
>>   \import{ absolute path }
>> when it exports the temporary files...
> 
> It is a strict policy that LyX does not touch ERT. So for this, native
> support for the import package would be required.

Not necessarily. External tenplates can be used as well. I attach a quick 
draft of a template for the \import command, together with an example .lyx 
file. If you want to use it, append the template to the file 
external_templates in your LyX installation. A template for the \subimport 
command can be constructed in the same way. The only thing you need to know 
are all those variables like $$AbsPath etc. These are described in the last 
chapter of the customization manual. With these variables you can construct 
any relative or absolute path you need. The external template definitions 
are a bit awkward, but it is a very powerful mechanism, and if you use an 
existing template as a base it is not difficult to create new ones.

> You can file an enhacement request for this, describing what this package
> achieves and why you think it is worth supporting it.

This might be a good idea nevertheless (for consistency with \input and 
\include). As I understand it, the package works around the uncommon 
handling of relative file names in LaTeX and is worth it to be supported: 
Relative paths in child documents are interpreted relative to the _master 
document_ in LaTeX. This is different from all other programs I know 
(including LyX), where relative paths in child documents are interpreted 
relative to the _child document_.


GeorgPreambleDef Import
\usepackage{import}
PreambleDefEnd

Template Import
GuiName "Import: $$AbsOrRelPathParent$$Basename"
HelpText
An imported LaTeX file.
HelpTextEnd
InputFormat latex
FileFilter "*.tex"
AutomaticProduction true
Format LaTeX
Product 
"\\import{$$AbsPath}{$$AbsOrRelPathMaster$$Basename$$Extension}"
UpdateFormat latex
UpdateResult "$$AbsPath$$Basename$$Extension"
Preamble Import
ReferencedFile latex "$$AbsPath$$Basename$$Extension"
ReferencedFile latex "$$AbsPath$$Basename.aux"
FormatEnd
Format PDFLaTeX
Product 
"\\import{$$AbsPath}{$$AbsOrRelPathMaster$$Basename$$Extension}"
UpdateFormat latex
UpdateResult "$$AbsPath$$Basename$$Extension"
Preamble Import
ReferencedFile pdflatex "$$AbsPath$$Basename$$Extension"
ReferencedFile pdflatex "$$AbsPath$$Basename.aux"
FormatEnd
Format Ascii
Product "[Import: $$FName]"
FormatEnd
Format DocBook
Product "[Import: $$FName]"
FormatEnd
TemplateEnd






import.lyx
Description: application/lyx

Re: no latex, dvi, ps, pdf output from lyx document

[Georg Baum]

Vincent van Ravesteijn wrote:

> Wolfgang Engelmann schreef:

>> Error 84 returned from iconv when converting from UCS-4LE to ISO-8859-15:
>> Ungültiges oder unvollständiges Multi-Byte- oder Wide-Zeichen
>> Converted input: 0x005c 0x0063 0x0069 0x0074 0x0065 0x0074 0x007b 0x0052
>> 0x0065 0x006d
>> Stopped at: 0x00b4
>> Unconverted input: 0x0065 0x0031 0x0039 0x0039 0x0031 0x007d
>> Converted output: 0x5c 0x63 0x69 0x74 0x65 0x74 0x7b 0x52 0x65 0x6d
>> File '/tmp/lyx_tmpdir.TJ6857/lyx_tmpbuf5/zelluhren20090214.tex' was not
>> closed properly.
>>  
>>
>> I tried to save it under another name: same problem.
>> I tried other outputs (latex, dvi, ps): same
>> I removed  File
>> '/tmp/lyx_tmpdir.TJ6857/lyx_tmpbuf5/zelluhren20090214.tex problem stays.
>>
>> What would the gurus propose to do?
>> I am using LyX1.6.1
>>
>> Thanks a lot for help
>>
>> Wolfgang
>>   
> I'm no expert on this, but there seems to be a wrong character in your
> document.

No, if you get this error it is either a bug in LyX or iconv. Error 84 is
EILSEQ, and the english error message is "An invalid multibyte sequence has
been encountered in the input". In this particular case we have the
sequence

0x006d (m) 0x00b4 (?) 0x0065 (e).

The acute is not part of ISO-8859-15, so iconv is indeed unable to do the
requested conversion. Therefore you have found a bug in LyX (it is supposed
to use the LaTeX command from the unicodesymbols file for characters that
are not part of the used output encoding).

Note that the text in question is not "Remé" but "Rem?e" since 0x00b4 is the
standalone version of the acute, so it looks like something else went
wrong. "Remé" would be encoded either as "0x0052 0x0065 0x006d 0x00e9" or
as "0x0052 0x0065 0x006d 0x0065 0x0301" (the combining acute is 0x0301).


Georg

Re: [Bug] LyX 1.5.6 ignores amsmath settings when adding \iint

[Georg Baum]

Guy Rutenberg wrote:

> Hi,
> 
> 
> On Sat, Oct 11, 2008 at 11:26 PM, Uwe Stöhr
> <[EMAIL PROTECTED]> wrote:
> 
>> OK, I used the default esint package math option, therefore I couldn't
>> see this. I don't know exactly, but remember that we only turn off
>> automatically detection of the amssymb package but not the amsmath
>> package to keep documents compilable.

If this is the case it is a bug IMHO. In earlier versions of LyX, if the
user set the ams math switch to off, amsmath was not loaded at all, even if
that would make the document uncompilable. The reason for this behaviour
was to solve problems like the one reported. There are a couple of commands
in amsmath that are also provided by other packages, and in some cases
those other packages are wanted.

> Is there a way to completly turn off the amsmath detection? If there isn't
> a gui option to do it, is there a simple way to disable it in the code?

You can probably comment it out in LaTeXFeatures.cpp.

> BTW is this behaivior expected to remain in future versions of LyX?

I hope not, it would be a bug IMHO.


Georg

Re: External_templates file format

[Georg Baum]

David Townshend wrote:

> On Tue, Oct 7, 2008 at 4:18 PM, rgheck
> <[EMAIL PROTECTED]> wrote:
> 
>> David Townshend wrote:
>>
>>> On Mon, Oct 6, 2008 at 1:52 PM, rgheck
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
 aquavitae wrote:



> Hi
>
> Can anyone tell me exactly how the external_templates file works?  I
> want
> to
> use datatool to plot some graphs, and I have the data in a csv file.
>  Just
> referencing the csv file in ERT (the code is
> \DTLloaddb{databasename}{filename}) gives the usual problems with
> relative
> paths, so I wanted to try to write a copier for it in
> external_templates.

copiers are not defined in the external templates file. Copiers are external
scripts that are called when files of certain formats need to be copied.
They are only needed if the _contents_ of the file to be copied needs to be
changed. I believe that you don't need that in your case.

> As far as the docs are concerned, they seemed to be fairly up to date.
> There's a lot thats unclear and not well detailed, but I don't think
> there's
> anything thats plain wrong.  To improve them I think they just need a lot
> more detail and examples throughout, e.g. under* 3.2.2 Copiers* there is a
> definition: *"$$l The 'LATEX name'." * Great, but what exactly is the
> *'LATEX
> name'*?

This is only needed in special cases (e.g. the tex_copy.py script that is
used top copy .pstex/pdftex files used by the xfig template from the temp
dir to the final location).

> Another example is in *6.2.1 The template 
> header*:*"AutomaticProduction true|false Whether the file represented
> by the template
> must be generated by LYX."*  Which file?

The final result as given by the UpdateResult line. If AutomaticProduction
is false then LyX does not call any converters, only the original file is
copied to the temp dir. Therefore this implies that UpdateResult is the
original file. 

> Does this mean whether the 
> copier
> should be called automatically?

No, the copiers are always called automatically.


Georg

Re: metafile2eps clips images

[Georg Baum]

Brookes, Mike wrote:

> I installed Lyx 1.5.6 on Windows using the standard installer but found
> that many images became clipped when converting from .emf (Windows
> metafile) to .eps format. After quite a lot of searching I disscovered
> that the problem lay in the settings of the newly installed metafile2esp
> pseudo-printer. In the "Device Settings" section of the printer
> properties the "Form to Tray Assignment" setting was A4 for both the
> "Tray" and "Manual" feeds. Setting these two parameters to "Huge" solved
> the clipping problem.

How exactly does it clip? If it removes some parts of the image, then it is
a bug. If it clips so that the bounding box of the converted image is
cropped exactly to the borders of the real image, then it is working
perfectly, and this behaviour is wanted. The reason is that emf/wmf files
often contain a huge white border, which is not needed, because LaTeX adds
the right amount of space to included graphics.


Georg

Re: Bug in listings inset (Lyx 1.5.6, OS X)

[Georg Baum]

Daniel Lohmann wrote:

> Actually, I had searched  bugzilla and found bug 4884 before asking on
> the list, but to me it does not really describe the problem of
> sorting. Now after re-reading the entry I  see that it is somewhat
> related, but that is not really obvious.

Yes, the problem in bugzilla is a different one, but the cause of both
problems is the strange parameter handling of the listings inset: In
the .lyx file the parameters are stored in one string in LaTeX syntax. The
same string is used for communication with the dialog. The intermediate
representation in memory is sometimes a vector, and sometimes a std::map.
Because of the latter the order of the parameters is not guaranteed at all,
and because of the "parsing" of the LaTeX string all sorts of other
problems can happen.

Both problems would be fixed by a sane parameter handling that would not
store all parameters in one string, but one parameter after the other in
the .lyx file. Preservation of order would then be easy to implement as
well.

> If you prefer I will add my suggestions there, otherwise I would open
> a new bug (with a reference to 4884).

Do as you like, I don't really care. There are good reasons for both
alternatives.


Georg

Re: Bug in listings inset (Lyx 1.5.6, OS X)

[Georg Baum]

Daniel Lohmann wrote:

> Hi,
> 
> I just discovered a "feature" of the listings inset that actually
> should be considered as a bug: Additional options given on the
> advanced page are implicitly sorted alphabetically. However, if using
> listing styles, the order of options is relevant. Consider the
> following example:

Yep, this is a known bug, caused by the manner how the parameters are
stored: http://bugzilla.lyx.org/show_bug.cgi?id=4884

Maybe you just add your suggestions there?


Georg

Re: Why the ugly PNG pictures?

[Georg Baum]

Aleksandar Kanchev wrote:

> Hello list,
> 
> whats wrong with LyX and PNG files?

Nothing. PNG files usually work fine.

> I draw a diagram in MS Visio, export 

Since Visio produces vector graphics it would be better to use a vector
format, e.g. EMF. Then you will not get any scaling problems. See
http://wiki.lyx.org/Windows/MetafileToEPSConverter for instructions on
getting good EMF/WMF support in LyX.

> it to PNG, open it on LyX 1.5.5 (on Fedora 9). The PNG looks  nice in
> LyX itself, but when I create a pdf the picture gets over-scaled beyond
> the page size. I tried forcing the picture size in lyx but it looked
> like it was first over-scaled, then scaled again to the size I gave it
> and as a result it looked completely ugly. This seems to be a problem
> with PNG files, I tried exporting from MS Visio the same file with the
> same size in JPEG and it displayed ok in LyX and the picture wasn't
> over-scaled I left it to automatically scale the picture.
> 
> Am I doing something wrong? Is there a known problem with PNG files?
> Could it be fixed? I really don't like JPEG, the diagram looks better in
> PNG. The picture size is 14x11,2 cm or 529x423 pixels.

It is the nature of bitmap files that the size is always measured in pixels,
never in physical length units like cm. Some bitmap formats do allow to
specify a resolution, so that you can relate pixels to physical lengths,
but this setting is usually ignored. In order to get predictable results
you should therefore avoid the setting "Original size" for bitmap files and
specify a fixed size, either in physical length units or LaTeX variables,
e.g. page width. If you get ugly looking PNGs you are probably not using
pdflatex (which supports PNG directly), and a bad PNG->EPS converter.


Georg

Re: Xfig and LyX

[Georg Baum]

Wolfgang Engelmann wrote:

>  with  external template way  you mean the way I and Rich use, i.e. export
>  fig
> to eps and insert in Lyx?

No. I mean what Abdel uses: Insert->File->External Material and then choose
the xfig template. In the file dialog you specify the .fig file. If you
want to edit the .fig file from within LyX press cklick on the file and
then press the edit button in the dialog that opens.

> Does it mean, I have to create the fig file after having started
> xfig -specialtext and xfig then puts my text in the pstex_t file with
> location marks etc?

No, the -specialtext switch is only the default for new textboxes. Therefore
it is useful, but it does not change existing ones. How the text is output
to LaTeX depends on the flags that are stored in the .fig file, not on
the -specialtext switch.

> With other words, I have to redo all my fig files and add (or copy, if I
> find out how the localization of the text is done in pstex_t)?

If they miss the flag, then you simply need to set the flag in the .fig file
(manually or with a script). No ned to look at pstex_t. Then you include
all .fig files as external material, and maybe set the preamble command
mentioned by Vasek.

> textbox is pstex_t?

No, a textbox is what you get when you press the big T in xfig and where you
enter your text.

> How does xfig find out the size and font I used in the document, or does
> it make latex take it over?

It does not find it out. It puts the text in a file that is processed by
LaTeX.


Georg

Re: Xfig and LyX

[Georg Baum]

Wolfgang Engelmann wrote:

> Am Mittwoch, 25. Juni 2008 13:26 schrieb Rich Shepard:
>>
>>I can try.
>>
>> > I have quite a number of xfig produced files which are all exported as
>> > .eps files and inserted in the LyX document as floats.

The external template way is supposed to be easier, since it does the
exporting automatically, so you can't get outdated figures because you
forgot to export.

>> > Do I have to use for all my fig files the xfig -specialtext or is there
>> > a global command to do that for all files in one run?

The special flag is a property of each text box that you have to set
individually. AFAIK the -specialtext switch only sets that as default for
new text. If you have a lot of files that you need to convert it would
probably easy to write a small script that does this.

> What about the size of the text in your fig -> eps file in respect to the
> size of the text of the body (that is the document text, I guess?). Do you
> adjust it just by comparing it? Thats what I did so far. But what about
> the pstex and the pstex_t which you get after running xfig -specialtext? I
> thought this is the way to divide the image part of the fig and the text
> part so that the latter can be adjusted (by the program) to the font size
> of my text (and also
> to include e.g. greek letters as latex etc). If I check my  pstex file, it
> still shows the image and the text, as it was in the normal .fig file. The
> pstex_t file reads like:

You should not need to worry about pstex_t and friends if you use the
external template. LyX is supposed to create all needed files
automatically, whether you use pdflatex or the traditional DVI. The only
decision you have to make is whether you want to use the special flag or
not: If you use it, the text will be typeset by LaTeX, and you can use
math, own commands that are defined in ERT or the preamble etc. The size
and font would also be adjusted through LaTeX commands. If you do not use
the special flag the text will appear as is in the final document, and you
set the font, size etc. in xfig.

>  I just did not get it yet, some step might be missing (perhaps something
>  in
> the preamble

You do not need to set anything in the preamble unless you use the xfig
special text flag and inserted nonstandard commands in a textbox of the
xfig file yourself.

>> > And how exactly do I get it into the document? Is it the pstex or the
>> > pstex_t file or both? Or is this done internally by LyX? With Enter
>> > (Einfuegen) File (Datei) external Material I get the fig file but the
>> > text of the pdf output is not scaled correctly (nor the fonts). Somehow
>> > I haven't caught the way of entering it.

If the special flag was set you encountered a bug, either in xfig, fig2dev
or in LyX. Otherwise just set the flag, and the text should be typeset by
LaTeX.


Georg

Re: Lyx 1.5.5 with Mac OSX 10.3.9

[Georg Baum]

Heike Zierau wrote:

> I think about the time that I changed the export options, when I wanted
> to write text in a text enviroment, not in a tex enviroment, all the
> letters of that paragraph turn diagonal and I can't read the text
> anymore. It goes back to normal after a while, but I still can't write
> in a way that I can read and see directly what I'm writing. (see
> attachments)

This is a known bug with LyX 1.5.5 on OS X 10.3.9:
http://bugzilla.lyx.org/show_bug.cgi?id=4907

It looks like the binary package for LyX 1.5.5 was compiled differently than
the previous versions. I'd really like to have a solution of this problem,
too!


Georg

Re: External fig material and pdflatex

[Georg Baum]

Abdelrazak Younes wrote:

> I got this error when I try to export with pdflatex:
> 
> Traceback (most recent call last):
>File "C:/devel/lyx/trunk/lib/scripts/fig2pdftex.py", line 81, in
>
>  tmp = open(epsfile + '.??', 'w')
> IOError: [Errno 2] No such file or directory:
> '0C__perso_these_fig_Avion.pstex.??'
> Error: Cannot convert file
> 
> An error occurred whilst running python -tt
> "C:/devel/lyx/trunk/lib/scripts/fig2pdf

I guess that your OS does not like the question marks in the file name.
Instead of using this strange name it would be better to use mkstemp() from
lyxpreview_tools.py to create a temporary file that deletes itself after
usage.


Georg

Re: External fig material and pdflatex

[Georg Baum]

Abdelrazak Younes wrote:

> Hello,
> 
> Does someone know if there is a version of fig2dev that does pdftex in
> addition to pstex?

Yes, newer versions support pdftex. And Angus implemented a workaround for
older versions in fig2pdftex.py, so it should not matter whether your
fig2dev supports pdftex or not.

> I am trying to use xfig drawing directly thanks to 
> the external material inset but that works only for plain LateX, not for
> pdflatex.

That is supposed to work out of the box.

> So this comes from transfig 3.2.3d and, AFAICS this is the latest version:

No. 3.2.5 is current, but that should not matter because of the workaround.

> Am I missing something or does the external xfig support is not prepared
> for pdflatex?

It used to be.


Georg

Re: Problems with LyX 1.5.5 after MAC OS X update

[Georg Baum]

Bennett Helm wrote:

> On Mon, Jun 2, 2008 at 2:40 PM, Georg Baum
> <[EMAIL PROTECTED]> wrote:
>> Which screenshot? Does it look like the problem in
>> http://bugzilla.lyx.org/show_bug.cgi?id=4907 ?
> 
> 
> It doesn't look like it. (I've attached the screenshot here.)

Yes, that is completely different. Do you have any idea about bug 4907? Or
is OS X 10.3.9 too old nowadays? That would be a pity, that machine is
ideal for travelling and has more than enough power for writing.


Georg

Re: Problems with LyX 1.5.5 after MAC OS X update

[Georg Baum]

Bennett Helm wrote:

> I don't know of anything that would affect it, and I haven't seen anything
> like that screenshot. I wonder if the file you downloaded was corrupted.

Which screenshot? Does it look like the problem in
http://bugzilla.lyx.org/show_bug.cgi?id=4907 ?

> Could you try downloading again and seeing if it works?

In case of that bug reinstalling did not help, and it did not crash.


Georg

Re: OT? Ligatures in pdf documents to be used in LyX

[Georg Baum]

G. Milde wrote:

> On 28.05.08, Juergen Spitzmueller wrote:
> 
>> The problem is that the copied characters are apparently wrong. The
>> clipboard should have the correct unicode code points for the ligatures,
>> but it has some completely different (and unrelated) chars.
> 
> They are not "wrong" but in a different encoding: witht the default
> settings, this is most probably the T1 encoding where ligatures are on
> places totally unrelated to the unicode points. (or even 0T1, where
> Umlauts will be "wrong" as well).

No, they are wrong. It is the task of the PDF reader to convert from the T1
encoding to an encoding supported by the OS. If it does not do that, it is
either a bug of the PDF reader, or the PDF does not specify the encoding
correctly. The latter has been the case with pdfs created from TeX several
years ago (IIRC more than 5), but this is fixed with current versions.


Georg

Re: OT? Ligatures in pdf documents to be used in LyX

[Georg Baum]

Rich Shepard wrote:

> On Tue, 27 May 2008, David Hewitt wrote:
> 
>> I get the same. If I try to copy from a PDF made with pdflatex, all the
>> ligatures show up as special characters and must be replaced. This is
>> with Computer Modern Roman font and standard classes (article, report).
> 
>This is to be expected. It's perfectly normal behavior. What should be
>the
> behavior if you block text in a pdf document (displayed with xpdf,
> acroread, or another viewer) and copy that text into emacs, pine, or
> AbiWord? The first two are text-mode applications, the last is a GUI. How
> is the clipboard to know what to do with the characters in it?

The application that puts the characters on the clipboard has to use an
encoding supported by the OS, and it has to specify the used encoding in
case the OS allows more than one. The details are different from OS to OS,
but the basic principle is the same.

This has not always been the case. AFAIK on unix the X selection was not
aware of the encoding originally, and many applications are still buggy in
this area, but today it is possible to transfer text through clipboards
without loss of information.
I don't know whether it works in emacs or pine, but I have no problems
pasting non-ASCII stuff into/from vim via the X selection, including
ligatures from kpdf. The ligatures are also transferred correctly to LyX.
They are not decomposed into single characters, and pdf creation still
works.


Georg

Re: Preferred way to write "c++"

[Georg Baum]

Neal Becker wrote:

> Sorry, I meant typeset the word: "c++".

http://tug.org/TeXnik/mainFAQ.cgi?file=misc/misc#cpp


Georg

Re: MS Word to LyX?

[Georg Baum]

Steve Litt wrote:

> Is there a way to transfer an MS Word document to LyX, preserving the
> paragraph and character styles in the document? I don't care how messed up
> it looks after transfer -- I can tweak the layout file to suit my needs,
> but I'd prefer not to lose styles.
> 
> Anyone know how to do that?

Translate it to .sxw with OOo and then use
http://www.hj-gym.dk/~hj/writer2latex/ in clean mode. It works pretty well
on structured documents, and you can even define your own mappings for
different styles.
This procedure probably requires some tweaking of writer2latex, but should
give pretty good results.
After that import the .tex file in LyX (might need some tweaking of the
syntax.default file as well).


Georg

Re: Compress file corrupted

[Georg Baum]

Bo Peng wrote:

> I have to say that, if this is indeed boost::iostreams' fault, I would
>  be really disappointed at the quality of boost libraries.

There is no single 'quality of boost libraries'. There are excellent
libraries, but there are also useless or complicated ones. And there are
unmaintained libraries (like iostreams).

BTW, did anybody file this as a boost bug?

> I think we can disable compression at 1.5.1, but allow reading of
> compressed files for backward compatibility.

Why introduce a regression if there is an easy alternative solution (use the
1.4.x code)?

> Anyway, this feature can 
> be replaced by the embedding feature that may be introduced in 1.6.0.

But 1.5.1 is not 1.6.0.


Georg

PS: Somebody should implement an easy to run (on all platforms) test suite.
This bug would have been found by it.

Re: References in Equations

[Georg Baum]

Am Sonntag, 1. Juli 2007 15:49 schrieb Martin Rauscher:
> I just tried to insert a reference within an equation with LyX.
> But LyX set it just BEFORE the equation.
> 
> I had to use ERT to reach my goal.
> 
> Bug, not implemented, or user error?

Bug. Works fine in 1.4.4.


Georg

Re: LFUNs in 1.5 RC1 (Windows)

[Georg Baum]

Steve Litt wrote:

> On Tuesday 19 June 2007 05:12, Georg Baum wrote:
> 
>> It is supposed to work if you convert the bind file from latin1 to utf8
>> (is this mentioned in the release notes?). All non-ASCII stuff in config
>> files has to be encoded in utf8.
>> If converting to utf8 does not help then it is a bug.
> 
> Does this include the copyright symbol and the trademark symbol?

I have no idea what symbols can be entered through self-insert. What I know
is that all symbols that can be entered need to be given in utf8 encoding,
and that all symbols that can be entered in 1.4 are supposed to work in
1.5, too. If you have a symbol that works in 1.4 but does not work in 1.5
then this is a bug.


Georg

Re: LFUNs in 1.5 RC1 (Windows)

[Georg Baum]

Dominik Waßenhoven wrote:

> Hi all,
> 
> I just tested the Windows 1.5 RC1 version which is a great improvement
> IMHO -- thanks to all the developers.
> 
> I have one problem so far, regarding LyX Functions. I use functions like
> the following in my bind file:
> 
> \bind "C-M-o"   "command-sequence self-insert ø"
> 
> This worked in LyX 1.4.3 without problems. However, this does not work
> any longer, because of the non-standard letter "ø". If I have, say,
> "command-sequence self-insert test", everything works fine. Is this a
> known bug or a new "feature"?

It is supposed to work if you convert the bind file from latin1 to utf8 (is
this mentioned in the release notes?). All non-ASCII stuff in config files
has to be encoded in utf8.
If converting to utf8 does not help then it is a bug.


Georg

Re: moving to linux...

[Georg Baum]

Helge Hafting wrote:

> Ares wrote:
>>
>> I thought that pdf, being a "portable document format", didn't need
>> any special setting on the machine you use.
> Now matter how portable - you still need pdf reader software.
> On linux there are several alternatives, some may be better
> than others. Some do a bad job with bitmap fonts, in particular.
> 
> A pdf without all fonts embedded isn't portable, it assumes the
> readers have  access to these fonts.  Now, there are some
> fonts that most people have, but you can't depend on it.

You can rely on exactly 14 fonts:
http://www.pdf-tools.com/asp/faq.asp?s=&q=58. Every pdf reader must provide
them (and I don't know any that does not have them), so it is safe (and
even recommended) not to embed these fonts. All other fonts must be
embedded.


Georg

Re: RC1 -- strange behaviour

[Georg Baum]

Stefan Schimanski wrote:

> Make a bug report in bugzilla please.

No. This is no valid .lyx file. A valid one would have

\backslash
_

(with the \backslash in its own line) instead of

\_

in the ERT. Adjust the script that generates the file, and it should work.
This syntax is used since at least 1.3, if your version worked before it
was pure luck.


Georg

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Georg Baum]

Dov Feldstern wrote:

> Back to RTL spaces:
> 
> The problem is this: almost always, the user just wanted a space between
> the previous word (which happened to be, say English) and the next one
> (which happens to be Hebrew), but by mistake pressed F12 before space
> and not first space and only then F12. In fact, I can't think of *any*
> case in which it is important to the user for it to be any other way.
> 
> However, I still think that it is more correct for us to pay attention
> to the language of spaces. If we don't, then there are things which I
> *would* like to be able to typeset, but won't be able to (see example
> below).
> 
> After thinking about this a lot, this is the solution I would like to
> see (I think it's similar to Georg's views, if I understood him
> correctly):

Yes, you did. I can't really tell how spaces should behave when inserting,
because I don't use RTL, but as long as all magic (if any magic is used at
all) only happens during/after inserting the space and not anywhere else
(drawing or export) I think the resulting code will be maintainable.
If you apply magic at different places then you will get a nightmare that
nobody understands in a few months anymore.


Georg

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Georg Baum]

Am Dienstag, 5. Juni 2007 21:06 schrieb Miki Dovrat:
> Lyx has an option of underlining the foreign text. What I meant was that 
I 
> always turn that off, so I can't tell which direction the spaces belong 
to.

Now I understand. I did not know that you can turn it off :-)


Georg

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Georg Baum]

Miki Dovrat wrote:

> The users (at least me) don't know whether the space is RTL or LTR because
> they don't "mark RTL code" since it is annoying to look at when writing a
> document in RTL.

I don't understand what you mean here. When you write a mixed hebrew/english
document you have to explicitly set the language of the foreign part
anyway. The spaces would simply be part of this mechansim, no extra
"marking" required.
Whether this explicit language setting should be replaced by some automatic
algorithm is a different issue that has been discussed. But even if such an
algorithm is implemented the result is still that each character has an
associated language that defines the direction.

> I don't know how difficult it is to code this, but I think the space
> should be "neutral", and that the direction should be decided according to
> whether the curser is currently to the right or to the left of this border
> space.

And how would you output such a neutral space to LaTeX? If you have visually
on screen

RTL LTR

where RTL is in RTL direction and LTR in LTR direction you need to decide
whether to output

\R{ LTR}LTR

or

\R{LTR} LTR}

to LaTeX. How would you decide which variant to use without an explicit LTR
property of the space? At first glance it might look as if both are
equivalent, but this is not the case if other font changes (e.g. size) come
into the play, and even if not your LTR font might have a different size of
the space as your RTL font. This is exactly the reason why spaces are not
handled specially anymore for font changes, and are output exactly as
entered.

> Lets say we have LTR RTL and the space between them.  If the cursor is to
> the left - continue English (you will be able to type another space there
> and continue writing), and if you are to the right of the border space,
> continue writing Hebrew (again, you will be able to enter another RTL
> space there as well). Extra spaces should then be removed, like lyx does
> today.
> 
> The same for RTL LTR.

The non-magic approach could be made to work exactly like that: If the
cursor is at such a boundary with a space, set the current font that will
be used for newly typed stuff either to the font at the left or the font at
the right, according to the rules you gave. Strictly speaking this is a bit
of magic, but I believe that in contrast to the neutral space this magic
could be implemented in a reasonable manner, because it would only affect
editing. A neutral space would require extra code in may different places.

The result would still be that each space has an associated direction, so
you could still create the other two cases of the four Stefan mentioned by
inserting and removing some temporary characters.


Georg

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Georg Baum]

Stefan Schimanski wrote:

> There are several possibilities now to interpret the underlined  
> spaces (short RTL spaces):
> 
> * The LyX 1.3 magic way: the RTL spaces behave in fact like LTR  
> spaces, i.e. they are put where non-underlined spaces would be. See  
> this example:

This magic has been removed on purpose for the case of font changes in
general (family, size etc), because the code to support it was complicated
and despite that not even correct.

>- In "english WERBEH_english" the _ is in fact behind the W
>  So in Latex you would write "english\R{HEBREW } english"

Rather "english\R{HEBREW }english".

> The consequence is that the cursor strangely (IMO) jumps from behind  
> the W to the right in the moment you enter the space. If you have  
> used LyX 1.3 you might be familiar with this behavior:
> 
>"english |WERBEHenglish" ==> "english WERBEH_|english"
> 
> If you continue now typing a character the cursor (and the space)  
> jumps back:
> 
>"english WERBEH_|" ==> "english |H_WERBEHenglish" ==>
>"english H_WERBEH_|english"
> 
> * The non-magic way: the spaces are no special characters. They stay  
> at the position you type them. See this example:

This is the solution that has been implemented for general font changes
since format 259.

>"english |WERBEHenglish" ==> "english |_WERBEHenglish" ==>
>"english |H_WERBEHenglish"
> 
> If you change back to English and continue typing the cursor will go  
> to the right, i.e.:
> 
>==> "english H_WERBEH|english" ==> "english H_WERBEH |english"
> 
> In Latex you would type the same:
> 
>"english \R{HEBREW H} english"
> 
> Of course two spaces, one inside the RTL, one outside, are merged  
> silently by Latex,
> i.e. "english \R{HEBREW }" will look the same as "english \R{HEBREW}".
> 
> If you have an opinion, please tell us.

Definitely the non-magic solution: If you enter a space it gets the
direction (RTL or LTR) of the current font, and is drawn on screen
according to that direction (place and underlining), and cursor navigation
follows that direction.
It should not be possible to enter two consecutive spaces (one in RTL and
the other in LTR) at a direction boundary.

This is IMO the best approach: Users see on screen exactly whether a space
is RTL or LTR. Therefore they know how the cursor will behave when
navigating. Removing the direction property from spaces might look more
user friendly at first glance, but the problem then is that you have to
perform some magic in the code that quickly gets so complicated that no
developer understands it anymore and/or it produces strange results in some
corner cases.


DISCLAIMER: I am not an RTL user, the idea behind this opinion is to make
the overall editing experience for all font attributes (size, family,
series, RTL/LTR etc) consistent.


Georg

Re: RC1 -- more remarks 2

[Georg Baum]

Jean-Marc Lasgouttes wrote:

>>>>>> "Georg" == Georg Baum
>>>>>> <[EMAIL PROTECTED]>
>>>>>> writes:
> 
> Georg> Hellmut Weber wrote:
>>> Hi Marc,
> 
> Georg> I guess you meant Jean-Marc here :-)
> 
>>> That's the effect i have to me quite often.
> 
> Georg> Known problem (but not scheduled to fix):
> Georg> http://bugzilla.lyx.org/show_bug.cgi?id=3427
> 
> Thanks for the pointer. Isn't it something fitCursor cold fix?

In don't know. The strange thing is that this bug does not seem to exist on
windows. If it were a fitCursor problem I would expect that it was platform
independant.


Georg