LyX Inserted Graphics Scale Error

[barisgerze@…]

I got error when scaling pictures ( not in editor ) in Turkish Language everything works fine with Document-Layout-Language settings for English but when I change it to Turkish and try to preview with dvi I get errors for every graphics ( 5 errors per graphics )
I looked 1.4.0 cvs version but still same error happening

[Georg Baum]

Could you please upload an example file with one graphic to this bug report?
Otherwise it is difficult to reproduce. Also the exact error message would be
nice to have.

[Georg Baum]

minimal test case

[Georg Baum]

* #2008 has been marked as a duplicate of this bug. *

[Georg Baum]

Note that the same happens if the language is set to french.

[lasgouttes]

This bug is LaTeX bug babel/3523:
​http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=babel%2F3523

The problem is that = is made active by turkish.ldf (it seems to happen
with latin too, but I am very dubious about french...).

This is a difficult problem, from what I gather, and it can be handled in two
ways:

• disable the = macro, with something like \shorthandoff{=} (maybe in the

lib/languages file

• use the xkeyval package (at least version 1.8) as outlined at the end of

the URL above.

[lasgouttes]

Concerning french, I'd be interested to see a testcase. I failed to
produce one.

[barisgerze@…]

Subject: Re: Lyx Inserted Graphics Scale Error

How can i disable \shorthandoff{=} ?
in lyx file ?
or where ?
and how can update xkeyvalue ?
btw i am using miktex on windows 2.4 version
i installed full.. how can i learn which version
i am using for xkeyvalue ?

thx

--- bugzilla-daemon@… wrote:

#2005

---

2005-08-30 14:13 -------
This bug is LaTeX bug babel/3523:

​http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=babel%2F3523

The problem is that = is made active by turkish.ldf
(it seems to happen
with latin too, but I am very dubious about
french...).

This is a difficult problem, from what I gather, and
it can be handled in two
ways:

• disable the = macro, with something like

\shorthandoff{=} (maybe in the
lib/languages file

• use the xkeyval package (at least version 1.8) as

outlined at the end of
the URL above.

---

You reported the bug, or are watching the reporter.

Start your day with Yahoo! - make it your home page
​http://www.yahoo.com/r/hs

[barisgerze@…]

i see that on latex bug list But i am confused about where will i write
this ? in lyx file with notepad?

To come back to the initial issue with babel and
graphicx, this will work with xkeyval v1.8:
\documentclass{article}
\usepackage{xkeyval}
\usepackage{graphicx}
\usepackage[turkish]{babel}
\begin{document}
\includegraphics[scale=.5]{rose.eps}
\end{document}

[lasgouttes]

Looking at turkish.ldf, it seems that = is made active to add some spacing
before this sign. So it is probably not wise to disable this with \shorthandoff.

Concerning xkeyval: try to add \usepackage{xkeyval} in your LaTeX Preamble.
See if it fixes you problem. If it does not, look at View>LaTeX lof file
and search for the place where xkeyval is loaded. You should see the version
number there (although there may be a better miktex solution, but I do not
know it).

[Georg Baum]

I can neither produce a french test case. I thought that #2008 was the same
bug and simply copied the information without testing first.

Jean-Marc, do you think that we should load the xkeyval package automatically?

[lasgouttes]

I am not sure what we should do actually. I fear that any clever solution
will create new problems. And we are never sure that xkeyval is new
enough to be useful, anyway.

This looks like a basic latex problem is is not ours to fix.

[Georg Baum]

I fear the same. On the other hand this behaviour is quite annoying from a
users point of view.
I added a note in ​http://wiki.lyx.org/LaTeX/LatexBugs. Should we close this as
WONTFIX?

[forenr@…]

Why not taking into account the shorthand characters in a given language
and surround \includegraphics with \shorthandoff{...} and \shorthandon{...}
commands?

As an example, for turkish it would be:

\shorthandoff{:!=}
\includegraphics...
\shorthandon{:!=}

whereas for french:

\shorthandoff{:;!?}
\includegraphics...
\shorthandon{:;!?}

Notice that this would also solve #2248, which is a different incarnation
of this one.

Care should be taken to not output \shorthand commands when babel is disabled.

[barisgerze@…]

Subject: Re: Lyx Inserted Graphics Scale Error

Very good idea. can you put that to new version of Lyx?

bugzilla-daemon@… wrote: #2005

---

Why not taking into account the shorthand characters in a given language
and surround \includegraphics with \shorthandoff{...} and \shorthandon{...}
commands?

As an example, for turkish it would be:

\shorthandoff{:!=}
\includegraphics...
\shorthandon{:!=}

whereas for french:

\shorthandoff{:;!?}
\includegraphics...
\shorthandon{:;!?}

Notice that this would also solve #2248, which is a different incarnation
of this one.

Care should be taken to not output \shorthand commands when babel is disabled.

---

You reported the bug, or are watching the reporter.

---

Bring words and photos together (easily) with

PhotoMail - it's free and works with Yahoo! Mail.<div id="RTEContent">Very good idea. can you put that to new version of Lyx?<br><br><br><b><i>bugzilla-daemon@…</i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> #2005<br><br><br><br><br><br>------- Additional Comments From forenr@… 2006-01-29 17:22 -------<br>Why not taking into account the shorthand characters in a given language<br>and surround \includegraphics with \shorthandoff{...} and \shorthandon{...}<br>commands?<br><br>As an example, for turkish it would be:<br><br>\shorthandoff{:!=}<br>\includegraphics...<br>\shorthandon{:!=}<br><br>whereas for french:<br><br>\shorthandoff{:;!?}<br>\includegraphics...<br>\shorthandon{:;!?}<br><br>Notice that this would also solve #2248, which is a different incarnation<br>of this one.<br><br>Care should be taken to not output \shorthand commands when babel is
disabled.<br><br><br><br><br><br><br><br>------- You are receiving this mail because: -------<br>You reported the bug, or are watching the reporter.<br></blockquote><br></div><p>

<hr size=1>Bring words and photos together (easily) with<br>

<a href="​http://us.rd.yahoo.com/mail_us/taglines/PMHM3/*http://photomail.mail.yahoo.com">PhotoMail </a> - it's free and works with Yahoo! Mail.

[lasgouttes]

This would make sense if babel allowed to shut off all shorthands
globally. We do not want to keep track of shorthands created by all languages.

[levon]

Not a regression, not 1.4.0

[Richard Heck]

Moving all bugs targeted to before 1.5.0 to 1.5.x.

If these are yours, please check that they have not been fixed and, if so, close
them.

Otherwise, sorry for the spam.

[Juergen Spitzmueller]

* #5256 has been marked as a duplicate of this bug. *

[Juergen Spitzmueller]

1.5.x is frozen. Shifting all 1.5.x-targetted bugs to 1.6.x.

If you have reported this bug, please verify if it still occurs in 1.6.0 and
close the report, if not.

[ps]

This would make sense if babel allowed to shut off all shorthands
globally. We do not want to keep track of shorthands created by all languages.

does this mean wonfix?

[lasgouttes]

I am ambivalent. Maybe we are waiting for babel to improve (or just die).

[Richard Heck]

Ping?

[Richard Heck]

OP says: It is fixed by babel things... layout setting.. but this workaround is annoying...

So I guess it is still open.

[Julien Rioux]

The duplicate #7577 includes a test case.

[lasgouttes]

It looks like adding \usepackage{xkeyval} as babel preamble for turkish would be the best solution. I think this should be available everywhere.

[Richard Heck]

JMarc, can you do that, or tell us how and where to do it?

[lasgouttes]

Require xkeyval.sty with turkish language

[lasgouttes]

I attached a simple fix. What I do not know though is

• is xkeyval generally available? (I think the answer is yes)

• can it lead with incompatibilities with other packages?

I would think it is safe enough. Georg, Uwe, any objection?

[Uwe Stöhr]

No objection.
But from where have you got the info about the workaround with xkeyval?

[Georg Baum]

This looks good. I also believe that xkeyval is generally available (it was already in tetex).

[lasgouttes]

Replying to uwestoehr:

No objection.
But from where have you got the info about the workaround with xkeyval?

See for example Section 10 of the xkeyval manual.

[lasgouttes]

Fixed in trunk at r39190.

OK for branch?

[Richard Heck]

This is not something I know about, so if you think it is safe, then please go ahead.

[Julien Rioux]

Although you test for the availability of xkeyval, how does the code in lib/languages uses that information? It seems to use xkeyval no matter if it's available or not, am I wrong?

[Juergen Spitzmueller]

Replying to jrioux:

Although you test for the availability of xkeyval, how does the code in lib/languages uses that information? It seems to use xkeyval no matter if it's available or not, am I wrong?

True. We could use something like this, though:

\IfFileExists{xkeyval.sty}{\usepackage{xkeyval}}{}

The test in chkconfig.ltx is still valuable, e.g. for the LyXConfig doc.

[Uwe Stöhr]

We could use something like this, though:
\IfFileExists?{xkeyval.sty}{\usepackage{xkeyval}}{}

In this case I would not add this. As explained in the xkeyval documentation, graphicx and Turkish with babel cannot work without xkeyval. So if we add the \IfFileExists statement and xkeyval is not available, the users will suffer from the bug without a chance to fix it.
Without \IfFileExists the user get an error message that xkeyal is missing and can install the package and everything will work fine. So in this case he at least know what to do to fix the problem.

But JMarc, can you please add an entry for xkeyval in LaTeXConfig.lyx?

[Juergen Spitzmueller]

Replying to uwestoehr:

In this case I would not add this. As explained in the xkeyval documentation, graphicx and Turkish with babel cannot work without xkeyval. So if we add the \IfFileExists statement and xkeyval is not available, the users will suffer from the bug without a chance to fix it.

Why? They have the same "chance" to fix it as without the statement. By installing xkeyval.

Without \IfFileExists the user get an error message that xkeyal is missing and can install the package and everything will work fine. So in this case he at least know what to do to fix the problem.

This argumentation presupposes that everyone uses graphics. I don't agree that we should break Turkish documents without installed xkeyval package in general just because it is needed with one specific (albeit widespread) package. A Turkish user who does not need graphics should ot get bothered by this.

[Uwe Stöhr]

Why? They have the same "chance" to fix it as without the statement. By installing
xkeyval.

Because they only see misscaled images and don't know that installing xkeyval would fix this. And clear, nobody is telling them this, so how can they know?
If they don't have xkeyval installed, they get a warning about a missing package "xkeyval" and know what they can do.

This argumentation presupposes that everyone uses graphics.

Sure. LyX should work for all documents and graphics are no special things. The vast majority use it. If users try out LyX and graphics don't work as expected, they will not use LyX further. I have seen users leaving LyX for much simpler things that didn't work because they thought LyX is buggy crap.

I don't agree that we should break Turkish documents without installed xkeyval

We don't break them. The user can install xkeyval and everything will work fine.
Following your argumentation we are in general not allowed to require new packages. But we did this in the past and will have to do this also in the future. Take for example the various layouts we provide. With every new version of these classes, the user will have to install new packages and other are no longer used. I had a lot of these cases during my recent review of our example and template files.

[Juergen Spitzmueller]

Replying to uwestoehr:

The vast majority use it.

How do you know?

We don't break them. The user can install xkeyval and everything will work fine.

So Turkish users need xkeyval even if they do not need graphics?

Following your argumentation we are in general not allowed to require new packages.

Sorry, but this is complete nonsense. I just object that we force installing a package even in contexts where the package is not needed.

If you think a message is needed, you can add a warning to the second argument of \IfFileExists. But forcing an error message on users unconditionally is clearly too harsh.

[Uwe Stöhr]

How do you know?

Lots of experience with students and many colleagues, especially with new users.
But tell me at least one user who does not even have a file with a graphic/image.

So Turkish users need xkeyval even if they do not need graphics?

Yes. And why not? This package doesn't harm and as soon they are using a graphic, they will need it anyway. And as said, I don't know any user who never used a graphic in one of its LyX files.

I just object that we force installing a package even in contexts where the
package is not needed.

This is in my opinion much too complicated. As soon as a graphic is added, the user will be in trouble. To avoid that he then either quit using LyX or send a mail to the list, we should require xkeyval and the Turkish users can use LyX for any purposes without having further troubles.

If you are not convinced, we should let another one decide, like JMarc, or discuss this on the list.

[Juergen Spitzmueller]

I'm not convinced. But I shut up.

[lasgouttes]

[I just discover that I was not in cc of this bug and did not see the discussion]

Replying to spitz:

Replying to jrioux:

Although you test for the availability of xkeyval, how does the code in lib/languages uses that information? It seems to use xkeyval no matter if it's available or not, am I wrong?

True. We could use something like this, though:

\IfFileExists{xkeyval.sty}{\usepackage{xkeyval}}{}

The test in chkconfig.ltx is still valuable, e.g. for the LyXConfig doc.

My point of view is that xkeyval is generally available. The test was here for the benefit of Miktex auto-package-download (ifs this still needed, Uwe?). I would be surprised these days that this package is missing somewhere. It has been last updated in 2008.

[lasgouttes]

Concerning the more general and heated discussion. The problem is of course not graphics, but all packages that use keyval.sty (a quick grep on my system gives me an estimate of 75 packages). A solution would be to load xkeyval when keyval is loaded (assuming the babel post preamble is inserted after all other packages).
Something like

  \ifx\setkeys\relax\else\usepackage{xkeyval}\fi

Note however that this is more fragile for the sake of being clever. I would not swear that it will always work. Actually, I would think there is a smaller risk of having an error by loading xkeyval unconditionally than of not applying the fix when it is needed.

[Uwe Stöhr]

The test in chkconfig.ltx is still valuable, e.g. for the LyXConfig doc.

My point of view is that xkeyval is generally available.

This is the case indeed.

The test was here for the benefit of Miktex auto-package-download (ifs this still
needed, Uwe?).

Yes, still needed although xkeyval is now in MiKTeX's basic package and therefore installed by default.

Concerning the more general and heated discussion...

The safest way is instead of using

\usepackage{xkeyval}

as done in r39190 is to use

\@ifundefined{rotatebox}{}{\IfFileExists{xkeyval.sty}{\usepackage{xkeyval}}{}}

This is super safe because then xkeyval will only be used if it is available and only if there are graphics in the file and only for documents using Turkish.

[lasgouttes]

Replying to uwestoehr:

as done in r39190 is to use

\@ifundefined{rotatebox}{}{\IfFileExists{xkeyval.sty}{\usepackage{xkeyval}}{}}

This is super safe because then xkeyval will only be used if it is available and only if there are graphics in the file and only for documents using Turkish.

I do not see the need to be "super safe" and restrict the change to graphics package use. The same thing will happen with any package using key=value syntax. I would remove the outer test, which does not fix a real problem. I tend to think that the other one is not necessary either, but I would not fight for it.

[Uwe Stöhr]

Sorry for the late repply.
I proposed it wit the outer one to assure that it is only loaded if the file contains an image. Jürgen's concerns were about that we load xkeyval even if no images are used.
If an image is used, we just need xkeyval and I don't see another way to help Turkish users.

[Richard Heck]

I'll leave it to you three to decide what to do. When you have agreed on something, it will be fine for branch.

[Vincent van Ravesteijn]

Putting this back on the radar. I would propose to either backport it to branch, or to change the milestone to 2.1.0.

[lasgouttes]

I do not have much to say beyond comment:45.

Personally, I would use \usepackage{xkeyval} unconditionally. Then we release it, and find a better fix if someone complains :)

[Richard Heck]

I have no strong opinion about this, or any opinion really. If JMarc is happy about what he committed to trunk, it's fine by me.

[Richard Heck]

Move 2.0.4 bugs to 2.0.5.

[lasgouttes]

Backported at [ee8f3f89/lyxgit].

[Richard Heck]

LyX 2.0.5 is finished.

[Richard Heck]

LyX 2.0.5 is released.

[Juergen Spitzmueller]

It might be worthwhile to check if the original bug still exists in recently released babel 3.9:
​http://www.tex-tipografia.com/babel_news.html

[Uwe Stöhr]

It might be worthwhile to check if the original bug still exists in recently
released babel 3.9

Yes, but it will take many months until this new babel version is wide spread enough.

[Juergen Spitzmueller]

The xkeyval workaround does not work any longer (TL 19).

[Juergen Spitzmueller]

Refixed in master at [1929caf4b7/lyxgit].

This could be fixed in stable by using hardcoded language names.

[Richard Kimberly Heck]

Sounds good to me.

[Juergen Spitzmueller]

Done at [1c2700eb11/lyxgit].

[Richard Kimberly Heck]

LyX 2.3.4 is done.