fast light toolkit and GUI independence
Dear Developers, I hope I won't be the n+199th to tell you this: I wonder whether the "fast and light toolkit" (fltk) could help Lyx towards GUI independence: it is fast, it is light, it works for both X-Windows and MS-Windows and a user on the jed-list stated that it facilitates GUI independence: On Tue, 6 Mar 2001 09:24:54 +0100 Charl P. Botha [EMAIL PROTECTED] wrote: FWIW, I've developed under both wxWindows and fltk, the latter for industrial use. wxWindows is a very good and extensive toolkit (it wraps almost anything) but fltk is mch more lightweight. If it's about wrapping only your gui and having it cross-platform, I'd say go fltk. An added philosophical advantage is that fltk facilitates (in fact motivates) the decoupling of UI and real functionality. may be that could be an option... Guenter (Please copy an eventual answer to me directly as I am not on the developers list) -- [EMAIL PROTECTED]
notes/comments proposal
Dear LyX-Developers, As I did not get a reaction from developers so far but support from a user, I'll send my note-inset proposal to the devel-list. (Or should I have filed it somewhere on a whish list?) (Could you mail me directly, or the users list, if there is some comment/reaction?) On Wed, 18 Jul 2001 00:02:39 -0400 wrote Matej Cepl [EMAIL PROTECTED]: Yes!!! This is something which I would love to have for a long time. Together with importing comments in LaTeX file into LyX as notes. Matej On 9 Jul 2001, at 13:56, Guenter Milde wrote: On Thu, 28 Jun 2001 11:54:16 -0300 wrote Ralph Boland [EMAIL PROTECTED]: Of interest, I also have to send versions of my papers to my supervisor or to co-authors. It would be very useful to be able to insert comments in the middle of a paragraph. e.g. (break sentence in two) (give reference) I guess margin comments are supposed to provide this facility. However I would like: 1) The comment marker to be more visible. Like the bright yellow and large box of the Note marker. 2) The ability to have the comment appear in the text rather than have to open up the marker (like math equations). This ability needs to controllable on an individual comment basis and on a global basis. 3) The ability to go to prev/next comment. Thus if someone has marked up my paper with comments I would like to be able to go through them one at a time. I would want to be able to program a key to do this. 4) I personally wouldn't want them printed as happens with margin comments. Personal tastes may vary here. I suppose this could be controllable too. 5) Note that a Note comment cannot be used here because it doesn't allow math equations etc. to be placed in them. Note, that almost all would be solved, if a Note would allow math etc. (I darkly remember, that there was something like open/close all for floats + the ability to toggle this by clicking) ... So my suggestion would be to make the note box more like a footnote box: i.e. it should not open a separate window but an inset (like floats, errors, ert-inset, and footnotes) and should (as a footnote or a comment) allow all the lyx-stuff like math, figures ... The difference to the Comment paragraph style would be like the one between LaTeX paragraph and ERT-inset (+ the Go To Note menu entry in the Navigate menu). Normal keybindings would work (xforms and KDE don't work well together, therefore my Del key does BS in all popup-windows, which sometimes is anoying. LaTeX export should also export notes (as comments, may be with a leading %Note:) (Then also optional printing is possible with the right package ...) What do other people think of this? Would this be much work or could some existing code be reused? Should I have posted to devel? Guenter -- [EMAIL PROTECTED]
Re: Breaking paragraph in a keepempty Section
On Thu, 28 Mar 2002 02:04:18 + wrote John Levon [EMAIL PROTECTED]: If this is the case why on earth didn't you open a bug ?! Becouse I am lazy (and did not have access when I recovered this one). However, now I did: http://bugzilla.lyx.org/show_bug.cgi?id=313 Guenter -- [EMAIL PROTECTED]
Re: [Bug 313] Enter key doesnot work in KeepEmpty paragraphs
Dear Developers,
On 12 Apr 2002 10:25:44 - wrote [EMAIL PROTECTED]:
[Bug 313] Enter key doesnot work in KeepEmpty paragraphs
Fixed!
Thanks for fixing. It will make the work with the Seminar class (and
the layout from the contributions site) a lot easier. I will update the
documentation (i.e. remove the warning about the bug) once 2.1* is out.
However, I have a second problem that makes work with Seminar a bit
complicated:
Besides the Environment and Item_Environment I'd appreciate a
Container_Environment tag for LatexType:
Environment: If preceding paragraph of same level is not of the same
environment type, insert a \begin{env-name} in the LaTeX
output before inserting the content of the paragraph. If the
next paragraph of the same level is not of the same
environment type insert an \end{env-name} after the content
of the paragraph.
Item_Environment: As Environment, plus
insert an \item before the content of the paragraph.
New:
Container_Environment: Always surround the content with \begin{env-name},
\end{env_name}
(The name Container_Environment is just my suggestion. I'd be happy if
some better name could be found.)
Needed for environments that serve as a container for other stuff (that gets
nested inside) and take some action with every new start of an environment
e.g. start a new slide with LandscapeSlide and PortraitSlide in
seminar.cls, start a new letter with letter in dinbrief.cls, or a new
article with clanek in the CSTUG bulletin layout. Currently, a dummy
paragraph (say {} in ERT and standard mode) is needed to separate the
environments.
I just filed a bug about this, but the bugzilla doesnot allow structured
text :-( so this letter will
a) express my thanks for your work
b) make the bug description a bit more clear (and hopefully understandable)
Guenter
PS: Please cc answers directly to me, as I am just normal LyX user and
hence only on the users-list.
--
[EMAIL PROTECTED]
Re: defaults
On Wed, 22 May 2002 04:14:54 -0700 (PDT) wrote [EMAIL PROTECTED]: I've searched high and low for reference to /$UserDir/templates/defaults.lyx which I finally figured out is how to set my document defaults. There's lots of data about templates and the lyxrc file but I can't find this one. Is this eluding me, deprecated, or is it not in the documentation? Seems like a documentation bug. (I learned about defaults.lyx only accidentially by regularly reading the lyx-users mailing list.) In the Customization guide, either in Section 2.1.2 directories or in the section 6.4 Creating Templates, a hint that defaults.lyx is the template used with FileNew would be nice. BTW: In my (1.1.6) de_Customization.lyx, the Section 2.1.2 Verzeichnisse (Directories) doesnot list the templates/ directory (the English version does). Günter -- [EMAIL PROTECTED]
Re: Re: seminar.layout doesn't work as expected
On 30 Jul 2002 10:37:28 +0200 wrote Jean-Marc Lasgouttes [EMAIL PROTECTED]:
On 17 Jul 2002 11:33:15 -0400 wrote German Poo Caaman~o
Since lyx-1.1.6-fix (AFAIR) I've been having some problems with
seminar.layout. I defined frames on my slides, but now one slide
appears with frame and empty, the second one appears with text
(without frame), etc.
Guenter From the attached file I guess, that the problem arises in
Guenter LyX 1.2.0 I have written seminar.layout for 1.1.6.
I just had another look at the example file from the LyX-tips: It is for
1.2.0 and it uses a seminar.layout that is different from mine, i.e. the one
in the contributed stuff section. (I wonder, if the new layout is included
in the standard 1.2.0 distribution. Also, I wonder whether it was written
based on my layout or not knowing it (or even before)...)
The two layouts have a different philosopy in dealing with the bug 341:
environment style vs. command styles for \begin{slide}, \end{slide}
- the two are non-compatible and must not be confused! :-(
- documents writtem with my seminar.layout will not work with the
1.2.0 layout and vice versa. :-(
Guenter
--
G.Milde at physik.tu-dresden.de
lib/languages polutonikogreek bug
Dear developers,
I have to admit that my latest patch for poytonic Greek, though
looking simple and innocent contained a bug that makes compilation of
(some) documents in polutonikogreek fail.
Fortunately, the fix is simple and even more simplifies lib/languages:
* as the special meaning of the ~ character in babel's polutonikogreek
is now cared for by LyX, we don't need special setup code.
--- a/lib/languages
+++ b/lib/languages
@@ -43,7 +43,7 @@ german germanGerman (old spelling) false iso8859-1
ngerman ngermanGermanfalse iso8859-15 de_DE
german-ch ngermanGerman (Switzerland) false iso8859-15 de_CH
greek greek Greek false iso8859-7 el_GR
-polutonikogreek polutonikogreekGreek (polytonic) false
iso8859-7 el_GR
\addto\extraspolutonikogreek{\let\~\char126}\addto\extrasgreek{\let\~\char126}
+polutonikogreek polutonikogreekGreek (polytonic) false
iso8859-7 el_GR
hebrew hebrew Hebrewtrue cp1255 he_IL
# hungarian is a synonym for the magyar babel language option
# hungarian might be used for special purposes, see http://www.math.bme.hu/la
The other part of this patch (change to src/LaTeXFeatures.cpp) is OK.
Should I post/upload the test files? Where?
sorry for the inconvenience,
Günter
Re: lib/languages polutonikogreek bug
On 2010-01-12, Jürgen Spitzmüller wrote:
Guenter Milde wrote:
* as the special meaning of the ~ character in babel's polutonikogreek
is now cared for by LyX, we don't need special setup code.
--- a/lib/languages
+++ b/lib/languages
-polutonikogreek polutonikogreekGreek (polytonic) false iso8859-7
el_GR
\addto\extraspolutonikogreek{\let\~\char126}\addto\extrasgreek{\let\~\char126}
+polutonikogreek polutonikogreekGreek (polytonic) false
iso8859-7 el_GR
...
This extra definition is there to enable accent-tilde with Greek.
Actually, the extra definition was already changed away from your
accent-tilde saving and is currently broken.
Also, as your accent-tilde saving code was only added to
'polutonikogreek' but not 'greek', accent-tilde always failed for
(monotonic) Greek where babel (re)defines \~ as \char126 too. (This is a
minor issue, as monotonic Greek does not use the perispomeni accent.)
Does this still work with your patch?
Accent-tilde works for polytonic Greek:
the “combining” feature does not place {} around the accented character
if the current language is polutonikogreek. The “input ligatures”
defined in the LGR font encoding then work to convert e.g. ~a to an
accented alpha.
It fails:
1. for Greek characters that cannot be encoded in the document encoding
because then we get e.g. \~\textgreek{a}
2. for '~'-accented characters in any other language inside a Greek
document (both polytonic and monotonic)
* if the textgreek feature is used (i.e. the document contains at
least one Greek char that is converted via the 'unicodesymbols'
file,
* except when the accented character is passed to LaTeX in a
suitable encoding.
See the test case attachments at the (closed) ticket 5976.
http://www.lyx.org/trac/ticket/5976
Fixes:
Bug 1
-
Problem:
The 'accent-tilde' LFUN places a COMBINING TILDE (Unicode char 0x0303)
behind the to-be-accented char and normalizes them if possible.
By default, the unicodesymbols file converts “char + COMBINING TILDE”
to \~{char}. Also, most normalized unicode chars (like ñ) are
expanded in the same way.
possible solutions:
a) apply combining before textgreek to get e.g. \textgreek{\~a}.
This would also solve cases like accent-circonflex α.
b) a sloppy normalization that merges greek car + COMBINING TILDE
to the corresponding GREEK char WITH PERISPOMENI
Bug 2
-
This is caused by the current (re)definition of \greektext with the
textgreek feature interfering with babels internal use of \greektext:
\providecommand*{\perispomeni}{\char126}
\AtBeginDocument{\DeclareRobustCommand{\greektext}{%
\fontencoding{LGR}\selectfont\def\encodingdefault{LGR}%
\renewcommand{\~}{\perispomeni}%
}}
\DeclareRobustCommand{\textgreek}[1]{\leavevmode{\greektext #1}}
\DeclareFontEncoding{LGR}{}{}
A possible fix is to change this to
\DeclareRobustCommand{\textgreek}[1]{\leavevmode{%
\fontencoding{LGR}\selectfont\def\encodingdefault{LGR}%
\renewcommand{\~}{\char126}%
\greektext #1%
}}
(patch for LaTeXFeatures.cpp below)
Alternatively, one could do without the renewcommand and use \char126 for
the perispomeni in 'unicodesymbols' (patch on request).
Thanks,
Günter
---a/src/LaTeXFeatures.cpp
+++b/src/LaTeXFeatures.cpp
@@ -195,12 +195,11 @@ static docstring const changetracking_none_def =
from_ascii(
\\newcommand{\\lyxdeleted}[3]{}\n);
static docstring const textgreek_def = from_ascii(
- \\providecommand*{\\perispomeni}{\\char126}\n
- \\AtBeginDocument{\\DeclareRobustCommand{\\greektext}{%\n
- \\fontencoding{LGR}\\selectfont\\def\\encodingdefault{LGR}\n
- \\renewcommand{\\~}{\\perispomeni}\n
+ \\DeclareRobustCommand{\\textgreek}[1]{\\leavevmode{%\n
+ \\fontencoding{LGR}\\selectfont\\def\\encodingdefault{LGR}%\n
+ \\renewcommand{\\~}{\\char126}%\n
+ #1%\n
}}\n
- \\DeclareRobustCommand{\\textgreek}[1]{\\leavevmode{\\greektext #1}}\n
\\DeclareFontEncoding{LGR}{}{}\n);
static docstring const textcyr_def = from_ascii(
Re: r33009 - in lyx-devel/branches/BRANCH_1_6_X: development/Win32/packaging/AltInstaller lib/doc lib/doc/de lib/doc/es lib/doc/fr
On 2010-01-13, Uwe Stöhr wrote: Am 13.01.2010 01:54, schrieb rgheck: The tutorial is a file for newbies and thus should only contain the basics. Another possibility would be to give more verbose error messages from tex2lyx, and perhaps in the GUI, error messages that would direct the user to the relevant part of the manuals. This can be done, however users with LaTeX classes we don't have a layout file are usually LaTeX experts. Not always. It could also be students given a university documentclass, first-time authors or converts trying to run a publisher's LaTeX template. By reading the relevant sections of the tex2lyx manpage and the references Customization manual it should in my opinion become clear how to handle layout files. However, pointing out the distinction between a LateX documentclass/-style and a LyX layout file and pointing to the relevant parts of the documentation will help them and, by reduced faqs, us. Günter
Re: tex2lyx and the manuals [was: r33009]
On 2010-01-13, rgheck wrote: On 01/13/2010 02:28 AM, Guenter Milde wrote: However, pointing out the distinction between a LateX documentclass/-style and a LyX layout file and pointing to the relevant parts of the documentation will help them and, by reduced faqs, us. Some of that material is still there, so we are still helped. But I still think, myself, that a more extensive discussion of the difference is important, and that it should be somewhere *most* users would encounter it, not just the ones who already know what they need to do. I also think that there ought to be a few paragraphs in the User's Guide about the possibilities for customizing LyX and why you might want to do that. Too few users know what is possible, it seems to me. Yes, the User Guide should/could have more pointers to other documentation parts. **And it should be easy to navigate them.** Therefore I propose: * Organize the help documents as children of one master LyX Guide. (enables easier cross-links and a common index). * Convert the LyX Guide to a set of HTML and publish on lyx.org. HTML is an easier to navigate format -- especially for newbies that are (yet) uncommon with the LyX way to navigate a document. While the lyx format should remain accessible to users (for better examples), the WYSIWYM markup at other places distracts from the content. (With the new native HTML export, it should also be possible to either let an installer (or Linux distribution package) convert the docs at install time or to convert on the fly and show in a browser.) Günter
Re: xml in lyx
On 2010-01-13, Andre Poenitz wrote: On Wed, Jan 13, 2010 at 06:36:09PM +, José Matos wrote: - what to do with math? Try to use the 'layout oriented' bits of MathML and invent our own for the few cases where there is no clean match. I suggest keeping math in LaTeX format (inside a inset type=formula tag). (This can be changed later, if there is public request and manpower, but math is a clear favourite for an incremental approach.) Independent of this: We could consider using Unicode characters for LaTeX macros which are supported by our 'unicodesymbols' file, e.g. β for \beta and ∫ for \int. Günter
Re: tex2lyx and the manuals [was: r33009]
On 2010-01-13, Pavel Sanda wrote: Vincent van Ravesteijn - TNW wrote: doesn't work because of different preambles and different needs of manuals. Which I still don't understand. http://www.lyx.org/trac/ticket/5460 only repeats this claim: to make that work through master/child is painfull due to the different demands of the manuals (preamble stuff, etc). but no further explanation/evidence. IMO * Creating a master file does not necessarily interfere with the child documents. All manuals should remain compilable as stand-alone documents. Maybe some adjustments would be needed to solve conflicting requirements. * Compiling the master would of course require all the requirements -- which not everyone has on his/her machine. However anyone able to compile all manuals should be able to compile the master. * Even if compiling the master proves impossible with LaTeX, it might be possible to export it to HTML. If a master file (without changes to the content of current manuals) is possible, we can decide on using this for cross-links (very helpfull in HTML and hyperlinked PDF). Also, while Uwe wrote in a comment to #5460: I don't see benefits of a single book as it would then also contain duplicate information. I would prefer to replace this duplicate information by navigable references to a canonical place. Günter
Re: r33007 - lyx-devel/trunk/lib/doc
On 2010-01-13, rgheck wrote: On 01/13/2010 06:34 AM, Jean-Marc Lasgouttes wrote: Of course, a better UI could be to transform a - into a -- (I do not have the unicode codepoint handy, sorry) when typing - after it (like spaces in math). A better UI *might* (and I do mean *might*) be to display it as a unicode em-dash. But you do not want that character, since LaTeX does not know it can break after, but not before, it. I offer the attached LyX file as proof. Then the unicodesymbols replacement definition 0x2014 \\textemdash # EM DASH is wrong. We could consider 0x2013 -- # EN DASH 0x2014 --- # EM DASH but I did not check for negative side effects. File a bug report? Günter
Re: r33007 - lyx-devel/trunk/lib/doc
On 2010-01-14, rgheck wrote: On 01/14/2010 03:24 AM, Jean-Marc Lasgouttes wrote: I think this is a case where we can just say : do like that now, this is the LyX philosophy... But there is no need to push this on the readers of the tutorial... Yes, and because it is the right way to do it, if we do say so ourselves. ... which I daubt. The way it is done now leads to bad spacing and related problems. You see them all the time in Word-produced documents. ??? I propose to replace all the Unicode glyphs with proper LaTeX dashes and to update the User's Guide to explain why --- and the Unicode version are NOT equivalent, even if they print the same character. I am against this. The Unicode version is more generic. Not all fonts will replace --- by an em-dash. Günter
Re: r33007 - lyx-devel/trunk/lib/doc
On 2010-01-14, rgheck wrote:
On 01/14/2010 11:39 AM, Jean-Marc Lasgouttes wrote:
rgheckrgh...@bobjweil.com writes:
The input ligature can have unwanted side-effects.
Copy the following into a LyX window:
To get help, use
# ls --help
Look at the PDF. I copied the text back from xpdf and got:
To get help, use
# ls –help
Trying this out, I get
ls: Ungültige Option -- e
„ls --help“ gibt weitere Informationen.
As Jurgen said, do you have an example?
Now, change the command to typewriter font and try again. This time it
helps, as typewriter is one example of a font without this input
ligature. But you also dont get an em-dash even if you mean one.
This is why e.g. Docutils exports -- as -{}-.
Why does LyX handle this differently from ~ and \?
And, as I've said, the Unicode
version gives the wrong spacing.
In the GUI window or in the output?
Spacing around an em-dash is both a font issue and a typographic one:
In German typography you put spaces around the Gedankenstrich (and
use an en-dash):
Halbgeviertstrich, länger als das Divis, steht zwischen zwei
Leerzeichen, außer in Verbindung mit Satzzeichen.
-- typokurz – Einige wichtige typografische Regeln
I don't think people writing
He came — and went.
will use correct spacing when told to use three hypens:
He came---and went.
spacing is the same.
And if the output is affected, the unicodesymbols file could replace
the em-dash with \tiny-space\textemdash\tiny-space{}
I think Guenter advocates the use of the unicode character on screen, and
--- in latex, using the unicodesymbols file (am I right?).
No. I'd prefer \textemdash\invisible breakpoint where
\invisible breakpoint is a generic version of the '' command
like -, but producing no hyphen sign (for compund
words with hyphen, e.g. x-y).
provided by e.g. the german babel option::
\decl...@shorthand{german}{}{\hski...@skip}
or (as suggested above) a tiny space (but again, this could interfere
with the fonts), hence my preference is no space.
If so, then I don't have any major objection, though, as someone said,
it is harder to distinguish the two glyphs visually than it is to
distinguish -- from ---.
True. But if I mean an em-dash, see --- and sometimes get this and
sometimes that, this is not WYSIWYM.
Günter
Re: xml in lyx
On 2010-01-14, rgheck wrote: On 01/14/2010 03:05 AM, Guenter Milde wrote: We could consider using Unicode characters for LaTeX macros which are supported by our 'unicodesymbols' file, e.g. β for \beta and ∫ for \int. Here again, unless we're proposing to write \beta as β and then read β as \beta, The other way round: I propose to use Unicode chars in the LyX file (so that if your write \hbar, the math editor would not only show ℏ in the GUI but also write it to the file. (\beta is a bad example, as we don't support it in math yet.) If you insert ℏ in a math editor window, the source view shows that LaTeX will see \hbar again. (As Unicode is forced in math, this holds also for UTF-8 output encoding.) I think you will see problems similar to those we were discussing with ---. LaTeX understands these sorts of macros not just as characters but as demanding certain sorts of spacing. --- is not a macro but an input ligature. Günter
Re: r33007 - lyx-devel/trunk/lib/doc
On 2010-01-15, rgheck wrote:
Before we have any more of this discussion, let me just emphasize that
my original concern was with the use of the Unicode emdash in the User's
Guide and Tutorial, where it gives bad results, according to the
standards of English typography. That is what I was proposing to change.
The issue about unicodesymbols was raised by someone else and is quite
orthogonal.
Nonetheless, we can discuss it. There is another issue about
how these things are rendered on-screen, and yet another about output,
again all orthogonal. But they too can be discussed.
In my view, the issues are:
a) What to use in the tutorial, --- or em-dash?
b) How to export the em-dash Unicode char to LaTeX?
c) Shall we pass --- directly to LaTeX even if it is not ERT also if this
breaks the WYSIWYM principle?
In my view,
* a) and b) are related, as if the Unicode glyph (correctly applied)
results in proper typography, it can be used in the Guide and Tutorial
without adverse effects.
* a) and c) are related too: we should not use --- if this results in
three hyphens in the printout.
On 01/14/2010 05:06 PM, Guenter Milde wrote:
On 2010-01-14, rgheck wrote:
On 01/14/2010 11:39 AM, Jean-Marc Lasgouttes wrote:
rgheckrgh...@bobjweil.com writes:
The input ligature can have unwanted side-effects.
...
# ls --help
Look at the PDF.
...
But if you put it in listings, or in a LyXCode environment, you get
what you would expect to get in those cases. In the LyXCode case,
that's because we find this:
ls~-{}-help
in the source. So LyX just handles this for you. I don't see anything
confusing about it.
Why does LyX handle this differently from ~ and \?
--- Typing three hyphens to get an em-dash is a TeX typing convention.
(TeX realises it with a font feature called input ligature.)
~ Typing a tilde to get a non-break space is another TeX typing
convention realised at the font level.
The quotation mark is an active character in some document languages
(e.g. German).
LyX handles this input in a way that
~ results in what I see (converted to \textasciitilde{}).
- confusing for TeXperts.
is handled by the smart-quotes feature (converted to typographically
correct quotes which I see in the LyX window).
If is copied from somewhere else or if the -key is unbound, it is
(at least in German documents) converted to \textquotedbl{}. To
access the special features for German typography that babel provides
via something, I have to use ERT.
--- is passed to LaTeX as-is also outside ERT and **without any visible
feedback**!
- confusing for non-TeXers
As Jürgen said, do you have an example?
Now, change the command to typewriter font and try again. This time it
helps, as typewriter is one example of a font without this input
ligature. But you also don't get an em-dash even if you mean one.
This makes perfect sense: Typewriters don't have em-dash keys. So the
em-dash is rendered as ---. Which is pretty much how people used to
type it.
I agree that this TeX feature in many cases gets it right. But nowadays
typewriter fonts have more characters than there are keys on a
typewriter, I would not like rendering of ä as a just because this is
how people used to type it in a (German) LaTeX source.
Another, more relevant example is XeTeX: If (like in the default LyX-svn
setup) system fonts are used, --- is rendered as three hyphens.
- Even if we decide to keep this TeX feature accessible without ERT, we
must not use it for the em-dash Unicode char.
And, as I've said, the Unicode version gives the wrong spacing.
In the GUI window or in the output?
Output. If you enter text[emdash]text, you do not get a line break
after the emdash. To get it, you have to mess around in ways you
shouldn't have to mess around. I'm not worried about spacing around the
em-dash.
Well, so I was misled by the wording wrong spacing to denote wrong line
breaks.
So my suggestion for issue b) boils down to:
EM DASH (U+2014) - \textemdash\textzerowidthspace
with \textzerowidthspace == ZERO WIDTH SPACE (U+200B)::
\providecommand*{\textzerowidthspace}{\hski...@skip}
also accessible as InsertFormattingZero Width Hyphenation Point
Though...
...
...it seems to me that this is *exactly* the kind of thing writers
should not have to worry about, i.e., that ought to be handled
automatically by the typesetting engine. If LaTeX doesn't do that, then
there should be a package that does it, if there isn't one already. If
there's no such package, then I'd be happy to consider special,
language-specific handling of spacing around --- and --, if you
wanted to propose that. But I would not want to have special spacing
around the Unicode glyph, since it is just a character, and maybe I
don't want special spacing around it: I meant to be able to use it as a
normal character, if I want to do so.
OK, this makes
Re: xml in lyx
On 2010-01-14, rgheck wrote: On 01/14/2010 05:28 PM, Guenter Milde wrote: On 2010-01-14, rgheck wrote: On 01/14/2010 03:05 AM, Guenter Milde wrote: I propose to use Unicode chars in the LyX file (so that if your write \hbar, the math editor would not only show ℏ in the GUI but also write it to the file. (\beta is a bad example, as we don't support it in math yet.) Of course we support \beta. Indeed, but we do not support Greek Unicode chars in math (β - \beta) currently. Anyway, I don't see the point of writing Unicode to the LyX file, only to have to translate it back. If ever we want to switch to a XML like math format, it should use Unicode where available. For an incremental transition, we could use Unicode chars in LaTeX format right now. Günter
Re: tex2lyx and the manuals [was: r33009]
On 2010-01-14, Pavel Sanda wrote: Guenter Milde wrote: On 2010-01-13, Pavel Sanda wrote: Vincent van Ravesteijn - TNW wrote: doesn't work because of different preambles and different needs of manuals. Which I still don't understand. http://www.lyx.org/trac/ticket/5460 only repeats this claim: no, the point was Uwe's reaction to the original proposal. he wants that manuals stay as they are and since he is the maintainer i respect it. to make that work through master/child is painfull due to the different demands of the manuals (preamble stuff, etc). but no further explanation/evidence. have you tried? I tried the link as I wanted to know details about the different needs but did not find them. I did not try to create a master for the Guides yet (as I wanted to find out more about the difficulties to expect first). As I do have experience in maintaining a master/child project with standalone-childs via branches, I expect to try this with the Guides once time permits. Günter
Re: r33007 - lyx-devel/trunk/lib/doc
On 2010-01-15, Jürgen Spitzmüller wrote: Guenter Milde wrote: Another, more relevant example is XeTeX: If (like in the default LyX-svn setup) system fonts are used, --- is rendered as three hyphens. Not here. But definitely here with LMRoman10-Regular. What fonts do you use? Jürgen
erratic undo behaviour with trunk
Dear LyXers, Trying out a recently updated and compiled LyX (SVN trunk) LyX 2.0.0svn (not released yet) Built on Jan 15 2010, 08:40:26 I have problems with the undo feature: * sometimes, when editing a test case for a bug report, undo will undo all changes since the buffer was opened in one step. * trying to reproduce this behaviour, it happens that undo is just well-behaved. Anyone else seeing this? Günter
Re: Metric (TFM) file not found
On 2010-01-21, Pavel Sanda wrote:
Pavel Sanda wrote:
i just tried to work on older document and got for compilation this error:
LaTeX.cpp(601): Log line: Missing character: There is no j in font nullfont!
LaTeX.cpp(601): Log line: ! Font LGR/lmss/m/n/6=gsmn0800 at 6.0pt not
loadable: Metric (TFM) file not fou
thats direct consequence of using $F_{\lyxmathsym{\textgreek{j}}}$ . sure i
can replace
it by normal \theta by i'm wondering why is stopped working.
This is one reason, why I would like to map Greek characters in math
to math symbols. (You will still be able to get the upright shape via
text-in-math.)
forgot to add that latin modern roman fonts were selected for this document.
I got greek fonts working also with lmodern, however no
emphasized/italic, small caps, or bold versions.
I fixed this with a homgrown fd file in my TEXPATH.
Günter
%%
%% This is file `lgrlmr.fd',
%%
%%
%% Copyright 2009 Guenter Milde
%%
%% based on lgrcmr.fd by Johannes L. Braams it makes the Greek CB fonts
%% working with the `lmodern' package.
%%
%% It may be distributed and/or modified under the
%% conditions of the LaTeX Project Public License, either version 1.3
%% of this license or (at your option) any later version.
%% The latest version of this license is in
%% http://www.latex-project.org/lppl.txt
%% and version 1.3 or later is part of all distributions of LaTeX
%% version 2003/12/01 or later.
%%
\ProvidesFile{lgrlmr.fd}
[2010/01/ v0.1 %
Greek Latin Modern]
\providecommand{...@family}[5]{%
\DeclareFontShape{#1}{#2}{#3}{#4}
{567891010.951214.4%
17.2820.7424.8829.8635.83genb*#5}{}}
\DeclareFontFamily{LGR}{lmr}{}
\...@family{lgr}{lmr}{m}{n}{grmn}
\...@family{lgr}{lmr}{m}{sl} {grmo}
\...@family{lgr}{lmr}{m}{it} {grmi}
\...@family{lgr}{lmr}{m}{sc} {grmc}
\...@family{lgr}{lmr}{m}{ui} {grmu}
\...@family{lgr}{lmr}{bx}{sc} {grxc}
\...@family{lgr}{lmr}{bx}{n} {grxn}
\...@family{lgr}{lmr}{bx}{sl} {grxo}
\...@family{lgr}{lmr}{bx}{it} {grxi}
\...@family{lgr}{lmr}{bx}{ui} {grxu}
\DeclareFontShape{LGR}{lmr}{b}{n}
{-ssub*lmr/bx/n}{}
\DeclareFontShape{LGR}{lmr}{b}{sc}
{-ssub*lmr/bx/sc}{}
\endinput
%%
%% End of file `lgrlmr.fd'.
Re: Metric (TFM) file not found
On 2010-01-21, Pavel Sanda wrote: Guenter Milde wrote: On 2010-01-21, Pavel Sanda wrote: Pavel Sanda wrote: I got greek fonts working also with lmodern, however no emphasized/italic, small caps, or bold versions. i was rather asking why document edited in lyx 1.6.2/3 stop working in 1.6.5/6. if its by different tex engine underneath - then well, what can you do... A different tex engine with working/not-working fallback font might be the reason. Another one could be changes to the document after the last compilation. Maybe you changed CM to LModern *after* the last successfull compilation or inserted the offending char afterwards? for normal user this would be quite problem since our error detection from latex log is wrong - it puts the cursor in wrong paragraphs without any idea what is the problem. This is why I asked for a Search in the latex log feature. (I am glad we have it now.) i'm not so average user and took me some while to understand what going on I agree that tex messages are sometimes hard to tell. Günter
Re: Trac rights
On 2010-01-25, Vincent wrote: Please, can we make the keywords, priority, severity and milestone fields to be editable only by people with rights. I understand that for people taking the step to report a bug, the bug is really major, but if everyone that reports a bug sets the milestone to the next minor release with priority high and severity critical, our organization gets lost. If not possible, please add documentation at a prominent place that these fields are reserved for use by the developers. Günter
Re: conflict during svn-update
On 2010-01-28, Jürgen Spitzmüller wrote: Sebastian Guttenberg wrote: Thanks a lot. Had to type it quite often, but it's fine now. Next time just delete all *.po files and svn up. Those *.po conflicts just happen, once in a while. Why are the *.po files under version control if they are generated and (once in a while) lead to conflicts? Günter
Re: XML?
On 2010-01-30, Steve Litt wrote: On Friday 29 January 2010 18:41:57 Peter Kümmel wrote: Am Freitag, den 29.01.2010, 17:55 -0500 schrieb Steve Litt: This example has no content. I'd be interested to see a real LuaTeX document in its native format. AFAIK LuaTeX is an engine (TeX to PDF converter) just like pdftex. It is fully backwards compatible, so all your documents should just work (at least if they work with pdftex). The lua interpreter is an addition. While lua scripts might look worse than your usual input file, the code can be *much* cleaner than many of the traditional packages and classes written in (La)TeX. Günter
Re: Goals for alpha 1
On 2010-02-01, José Matos wrote: On Friday 29 January 2010 22:38:05 Peter Kümmel wrote: So I propose to rename it to 0.19 because we have always evolved and never had any real revolution. We had the transition to Unicode but missed it (version number wise). LyX 1.6.x is a different beast from 1.0.0 and yet you insist to have the same initial number. The change to a new major number is longer overdue. In my view, it does not make sense to jump from 1.6 to 2.0. Even if there are new features, there is also continuity in the base code. I'd wait with 2.0 for the XML file format, as even if not seen by the average user, this is a change at the very base and the numbe scheme can serve to highlight this hidden revolution. Günter
Re: XML?
On 2010-02-01, Steve Litt wrote: On Monday 01 February 2010 05:24:30 Vincent van Ravesteijn - TNW wrote: OK, I guess my question is this: If LyX were using LuaTex, what would my LyX document look like in Vim? I'd rather make sure you won't need vim anymore :). That's not gonna work. One of my reasons for switching to LyX was that I *could* use Vim. A Vim-disabled LyX is just MS Word with better formatting. While not using Vim but Jed, I second the statement that there are task that are more efficiently be done in a text editor. This is why I would greatly welcome improved support for external editing of the lyx source: * open file of current buffer in a configurable application, reload buffer once this application is closed. * open a lyx file in LyX and jump to a specified place/line, so that I can easily go to `grep` results or the place I have been editing in my valued text editor. Günter
Re: XML?
On 2010-02-02, Tommaso Cucinotta wrote: Guenter Milde wrote: This is why I would greatly welcome improved support for external editing of the lyx source: * open a lyx file in LyX and jump to a specified place/line, so that I can easily go to `grep` results or the place I have been editing in my valued text editor. such use-case scenario would become much less likely to happen with Advanced Search, wouldn't it be ? Prabably. I am not (yet) familiar with the power and usage of the new interface. So I cannot tell whether it will be able to do regexp replacements in math, say. However, grep for a phrase in a set of lyx documents (all papers of the last 3 years, say) is still a valid case. Günter
Re: XML?
On 2010-02-03, Pavel Sanda wrote: Guenter Milde wrote: This is why I would greatly welcome improved support for external editing of the lyx source: * open file of current buffer in a configurable application, reload buffer once this application is closed. i feel this is task for only very advanced users and we shouldn't promote editing lyx file directly in our gui. as for your usecase, try: vc_command DR my-editor $$p/$$i Thanks for this tip. However, trying this in the minibuffer of my LyX 1.6.5, with a lyx file from my home dir, I did get no reaction from LyX (except mirroring the command in the status bar) and the line Das Verzeichnis ist nicht lesbar. (The directory cannot be read.) in the .xsession-errors file * open a lyx file in LyX and jump to a specified place/line, so that I can easily go to `grep` results or the place I have been editing in my valued text editor. not easy to do as discussed in bugzilla. I know, but still desirable. Günter
Re: XML?
On 2010-02-02, Tommaso Cucinotta wrote:
Guenter Milde wrote:
However, grep for a phrase in a set of lyx documents
(all papers of the last 3 years, say) is still a valid case.
sure, that's something at which grep is surely unbeatable and faster.
Now combine this with locate to search the whole system:
grep my-pattern `locate *path-pattern*lyx`
...
Anyway, I think an XML file-format would almost certainly preserve the
grep ability, and within certain boundaries I guess also a
regex-based replace.
I even think a properly written XML can be easier to parse/grep, e.g.
by inlining inline tags like::
Some
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\end_layout
\end_inset
silly
\begin_inset ERT
status open
\begin_layout Plain Layout
}
\end_layout
\end_inset
text.
\end_layout
with::
Some ERT status='open'{/ERTsillyERT status='open'{/ERT text.
Günter
line breaks in variable width table columns
This came up in the users list, but boils down to a feature request:
It would be nice if LyX could interpret a Ctrl-Enter in a variable-width
table cell as insert the content in a \shortstack with a line-break at
this place.
On 2010-01-28, Guenter Milde wrote:
On 2010-01-27, Uwe Stöhr wrote:
Vincent schrieb:
I have to set the table column widths [...], and then, possibly,
Ctrl+Enter will make the new line anyway.
Yes, you have to set a column width :). Don't ask me why.
This is LaTeX. There is no other way because otherwise the width cannot
be calculated at which the line break should occur.
But this is a technical restriction. A fixed witdth is required for
automatic line wrapping. With manual line-breaks the column width can be
calculated from the maximal line length.
However, LaTeX does not allow manual line-breaks in a table cell.
A workaround is to use the \shortstack macro (currently as ERT).
This would lead to e.g. the following LaTeX source:
\begin{tabular}{|c|p{3cm}|}
\hline
\shortstack{not so\\short\\stack} fixed\\
width\tabularnewline
\hline
\end{tabular}
The vertical alignment needs some improvement, but generally this works.
Günter
Edit buffer in external editor
On 2010-02-04, Pavel Sanda wrote: Thanks a lot Pavel, vc-command DR $$p my-editor $$i (with - instead of _ in the command name) works like a charm. This solves a long-standing issue for me. Binding this with the ToolsSettingsKeybindings dialogue failed, however: after saving, the command is truncated to vc-command DR $$p Looking in the generated user.bind file, I found that the whole command is put into quotes. Trying again with escaped quotes: vc-command DR $$p \my-editor $$i\ solved this issue. (Should the keydindings dialogue insert the quotes automatically?) I bound the function to F4. Is there a preferred/usual keybinding for external edit in CUA-aware applications? Günter
Re: Wishlist items - document templates
On 2010-02-04, Helge Hafting wrote: File-New from Template currently shows only templates in /usr/share/lyx/templates. The dialog ought to have a couple of shortcut buttons: system templates and private templates that goes directly to these two directories. Seconded. The reason is to have easy access to both the templates that comes with lyx, as well as self-made templates. Navigating the filesystem from one place to another is too cumbersome. For the time beeing, I use the following workaround: * Set the template directory to my private templates (LYXHOME/templates) in ToolsSettingsPaths. * Place a symlink to the system templates in my private templates Günter
Re: Edit buffer in external editor
On 2010-02-05, Pavel Sanda wrote: Guenter Milde wrote: (Should the keydindings dialogue escape quotes automatically?) dunno, please put this into bugzilla. Done. http://www.lyx.org/trac/ticket/6511 Günter
Re: texlive language packages
On 2010-02-05, Hartmut Haase wrote: in two cases I already found, that texlive does not install language packages automatically, if you install lyx through the package manager: ubuntu and openSUSE. Same on Debian. This is normally *the right thing* as the lyx package should not bring more dependencies than really required and this differs depending on the languages that you really want to write in (or use features of). I wanted to put a note into splash.lyx but Uwe wants to discuss it here. I don't think splash.lyx is the right place, rather the tutorial or intro. Günter
Re: Another Lyx Error Detected
On 2010-02-08, Lara Pagano wrote:
Another problem I am having is with too many floating figures. I have a
large document with anywhere from 3-100 figures within each chapter. I keep
getting the error regarding too many floats. I worked around this issue by
placing /clearpage every so often to make it produce a PDF. However, the
blank pages it is producing is something I need to get rid of. How do I
combat this issue given the amount of figures I have??
Changing the LaTeX parameters for float placement in the LyX preamble, e.g.
\renewcommand{\textfraction}{0.5}
\renewcommand{\topfraction}{0.5}
\renewcommand{\bottomfraction}{0.5}
\setcounter{totalnumber}{50}
\setcounter{topnumber}{50}
\setcounter{bottomnumber}{50}
Günter
Re: [patch] implement multirow support - request for help
On 2010-02-09, Uwe Stöhr wrote: Attached is what I currently have to support multirows. There is currently one issue I cannot solve: The metrics and drawing of the cells that are part of a multirow is broken. The drawing of the first multirow cell is however correct. I failed to figure out this problem and therefore ask for help. Has anybody had time to have a look at this? Not me, however, I have a maybe similar problem with another LaTeX frontend -- Docutils: If you download and compile http://svn.berlios.de/svnroot/repos/docutils/trunk/docutils/test/functional/expected/standalone_rst_latex.tex you will realize a broken border in the rowspanning tables example on page 13. The reason is identified as different table models In the LaTeX `multicol` package, if there are multirow cells, the overwritten cells need to be defined as empty cells. Docutils (similarily to HTML) uses is the Exchange Table Model (also known as CALS tables, see soextblx.dtd_) which defines only the remaining cells in a row affected by multirow cells. Therefore, visit_entry() is only called for the remaining cells and the LaTeX writer needs bookkeeping to write out the required number of extra ''s. .. _soextblx.dtd: http://www.docbook.org/sgml/4.2/soextblx.dtd I don't know whether this is related or not but maybe this can be a hint. Günter
Re: [patch] 6534: fix unicode issues in bibitem
On 2010-02-12, Jürgen Spitzmüller wrote: Currently, a unicode glyph (outside the output file's encoding) either in the label or in the key yields a silent iconv error ... The attached patch against branch solves both issues. Objections, comments? Thanks. However, the silence of the iconv error (the document is not output, but the user gets no warning either). should be adressed in a generic way as well (not only iconv but any helper application) (as this can happen also with unknown glyphs). Günter
wrong hint change the encoding to UTF8
Dear LyX developers, once again, a post on lyx-users regarding the wrong hint: changing the encoding to UTF8 might help displayed with encoding errors. LyX's unicodesymbols file is more complete than inputenc's utf8 definitions, so this is just misleading. On 2010-02-15, Jürgen Spitzmüller wrote: Mike Scroggs/Connie Graham wrote: ... when I try to view the PDF it gives this error message: Could not find LaTeX command for character ' ' (code point 0x2028) ... It says changing the encoding to UTF8 could help, but that's what I already chose. ... For now, your best bet is to open View Source, search for the character (it is marked in red in the source), and remove it. This is by far a more useful troubleshooting hint, so pleas let this be shown instead of the obsolete one. Günter
Re: wrong hint change the encoding to UTF8
On 2010-02-22, Jürgen Spitzmüller wrote: Guenter Milde wrote: LyX's unicodesymbols file is more complete than inputenc's utf8 definitions, so this is just misleading. Probably yes. For now, your best bet is to open View Source, search for the character (it is marked in red in the source), and remove it. This is by far a more useful troubleshooting hint, so please let this be shown instead of the obsolete one. I'm not sure if remove the offending char is always advisable (it was in the given case). I'd say replace the offending char, which could mean remove (for invisible chars) or substitute with either a supported Unicode char or ERT. I'd also suggest to report the problem, if possible with a LaTeX replacement recomendation. Thanks, Günter
Re: Greek text mixed with English
On 2010-02-25, Νίκος Αλεξανδρής wrote:
I use LyX and (probably) only LyX for everything that has to do with
writing a nice--clean looking text/ document. I would love to see the
Greek-English problem solved once and forever [1].
I mean, to set the language in Greek, write your stuff in Greek and in
English _without_ the need to set, for the latin part of the text, the
English language.
Hence my question: how much time/money would it take for some dev(s?) to
get this Greek-English problem fixed once and for all?
It is solved. Maybe not as you intended, but as a working workaround
that could be converted in a LyX module.
However this needs testing, so if you volunteer to help and test, maybe
we can get this into the next release.
I've been not messing around with LyX for quite some time. I don't
remember exactly what was the background mechanism (babel) which causes
Latin characters to be converted in Greek.
The trick is to have latin text as default and let LyX (or the autofe
package) do the work converting Greek letters to LaTeX commands).
Try to insert the TeX code below in the LaTeX preamble and set the output
encoding to ASCII.
Günter
% Do not convert ASCII chars to Greek
% Use this together with the languages Greek or Greek (polytonic)
% and the ASCII output encoding.
\AtBeginDocument{% (i.e. after loading babel)
\addto\extrasgreek{\latintext}%
\addto\captionsgreek{%
\def\prefacename{\textgreek{Pr'ologos}}%
\def\refname{\textgreek{Anafor'es}}%
\def\abstractname{\textgreek{Per'ilhyh}}%
\def\bibname{\textgreek{Bibliograf'ia}}%
\def\chaptername{\textgreek{Kef'alaio}}%
\def\appendixname{\textgreek{Par'arthma}}%
\def\contentsname{\textgreek{Perieq'omena}}%
\def\listfigurename{\textgreek{Kat'alogos Sqhm'atwn}}%
\def\listtablename{\textgreek{Kat'alogos Pin'akwn}}%
\def\indexname{\textgreek{Euret'hrio}}%
\def\figurename{\textgreek{Sq'hma}}%
\def\tablename{\textgreek{P'inakas}}%
\def\partname{\textgreek{M'eros}}%
\def\enclname{\textgreek{Sunhmm'ena}}%
\def\ccname{\textgreek{Koinopo'ihsh}}%
\def\headtoname{\textgreek{Pros}}%
\def\pagename{\textgreek{Sel'ida}}%
\def\seename{\textgreek{bl'epe}}%
\def\alsoname{\textgreek{bl'epe ep'ishs}}%
\def\proofname{\textgreek{Ap'odeixh}}%
\def\glossaryname{\textgreek{Glwss'ari}}%
}
\let\captionspolutonikogreek\captionsgreek
\addto\captionspolutonikogreek{%
\def\refname{\textgreek{Anafor`es}}%
\def\indexname{\textgreek{Euret'hrio}}%
\def\figurename{\textgreek{Sq~hma}}%
\def\headtoname{\textgreek{Pr`os}}%
\def\alsoname{\textgreek{bl'epe ep'ishs}}%
\def\proofname{\textgreek{Ap'odeixh}}%
}
\def\dategreek{%
\def\today{\number\day \space \textgreek{...@month}\space \number\year}}
\def\Grtoday{\textgreek{%
\expandafter\Greeknumeral\expandafter{\the\day}\space
\...@c@month \space
\expandafter\Greeknumeral\expandafter{\the\year}}
}
}
Re: #6558: Edit-Language lacks keyboard shortcuts.
On 2010-02-25, Jürgen Spitzmüller wrote: Jean-Marc Lasgouttes wrote: Thanks for the work on the language menu, while there is still room for improvement, I think it is going in the right direction. in the rather usual case when only one language is used ... ... This new menu entry is a regression in terms of usability IMO. If you think so, fine with me. I remebered that people do not easily find that language is to be set in the character dialog. Actually, I'd prefer to move the language setting out of the character dialogue completely. Language is an important semantic feature, while all other settings in this dialogue concern presentational markup. Günter
trunk: Font change in XeTeX sets black background!
On 2010-02-27, Liviu Andronic wrote: --0016e656b5989321f8048092a3d5 Content-Type: text/plain; charset=UTF-8 On 2/27/10, Guenter Milde mi...@users.berlios.de wrote: It works here, with both Charis SIL and DejaVu as document fonts (LyX-2.0 makes it easy to select fonts for XeTeX :-). Other than some SVN bugs (getting all-black PDF after changing font with XeTeX enabled), with DejaVu it worked out of the box (View PDF (XeTeX)). I got the black background too, but could change it to white (or default) under DocumentSettingsPage Layout. However, changing the font again also brought back the black background as side effect. Günter
Re: Greek text mixed with English
On 2010-02-27, Vincent van Ravesteijn wrote: Νίκος Αλεξανδρής schreef: Would it be possible to set the language automatically when recognizing a certain unicode range ? While possible, it is ambiguous (and therefore not helpful): * Cyrillic: Russian, Bulgarian, Serbian, Church Slavonic, Ukrainian, ... * Latin: German, Dutch, Swedish, Vietnamese, ... * Greek: polytonic or monotonic Greek, Coptic, ... For example, when I enter japanese, I get uncodable character ... in my LaTeX if I don't mark it explicitly to japanese. Instead, can't we just set the language to some default language for which this character is encodable. Generally, Unicode characters should work independent of the text language. This works (mostly) in LyX. However, if your output encoding (i.e. LaTeX's input encoding) is set to UTF-8, the conversion is done by LaTeX's inputenc package that (partially) depends on the language setting. It seems a bit annoying if you switch from english to japanes, you have to change your inputmethod and to change the language. This topic came up with Greek/English as well. My recommendation is to create a keybinding that does both with just one key-combo (either as command-sequence in lyx or as an external script that changes the input method and pushs a language switch command to the lyxpipe). We can even specify a secondary or tertiary language in the Document Settings. This can then also be used to automatically set the language based on the spellchecker results. Vincent
Re: Greek text mixed with English
On 2010-02-28, Vincent van Ravesteijn - TNW wrote: Vincent van Ravesteijn - TNW wrote: This is my interpretation of the problem: unexpected output of greek characters while there are latin characters on screen. Yes, this is the OP's problem. Maybe it should rather be named: words using written with Latin letters in a Greek document. The OP writes Greek using a Greek keyboard, so the conversion of Latin letters via transliteration is an unwanted and unexpected effect. Which I would judge an information deficit. We should communicate better why languages need to be marked in LyX (and why this is a good thing). So, we show the characters in greek also on screen. That seems the best way to communicate to the user that these characters will be converted. But this is just one side. A filename, a C command or some Acronym in a Greek document do not gain from beeing marked as another language but still should keep Latin letters as such! I see room for both, Greek with transliteration of Latin input (for the occasional Greek quote in a non-Greek document) and Greek with Unicode input (where Latin characters remain Latin). Instead of 4 Greek language variants to care for the combinations: monotoniko polutoniko transliteration12 Unicode34 I suggest a GreekUnicode Module. Günter
Re: Greek text mixed with English
On 2010-02-28, Jürgen Spitzmüller wrote: Vincent van Ravesteijn - TNW wrote: Yes, that's exactly the point. If there are latin characters on screen in LyX, we don't want to have greek letters appearing in the output right ? No. If I use the transliteration, I want exactly this. Even though the latin characters are marked as greek language (which would only affect the spellchecking, hyphenation... ? Or is this a feature ? Yes, it's a feature,as you noticed in the meantime. It is a feature that dates back to pre-Unicode times (actually even back to 7bit ASCII times). It is still handy for the occasional Greek quote for people without Greek keyboard, but stands in the way for others. This is why this feature should be optional. As I see it, the user wants a quick way to switch between two commonly used languages (a good shortcut for language greek and language english or bind that functions to the action Greek users perform to switch between English and Greek, if any). This is just one side. The other is to keep Latin input of e.g. a file name in Latin spelling. Günter
Re: Greek text mixed with English
On 2010-02-28, Vincent van Ravesteijn - TNW wrote:
I think we should output \textlatin for the latin characters as we do
with \textgreek for greek characters.
I thought about this once, but this would make Greek even more the odd
one out, because e.g. Cyrillic does not work this way:
Language English:
\textcyr{\char254} \textgreek{a} a % ASCII
or
я α a % Unicode
Language Russian:
\textcyr{\char254} \textgreek{a} a % ASCII
or
я α a % Unicode
Latin characters in a text marked as Russion are not transliterated.
It is just Greek that even in Unicode converts Latin to Greek
Language Greek:
\textcyr{\char255} a\textlatin{a} % ASCII
or
я α\textlatin{a} % Unicode
This can be solved with
\addto\extrasgreek{\latintext}%
and then:
Language Greek:
\textcyr{\char255} \textgreek{a} a % ASCII
or
я α a % Unicode
Günter
Re: Greek text mixed with English
On 2010-03-01, Jürgen Spitzmüller wrote: Guenter Milde wrote: But this is just one side. A filename, a C command or some Acronym in a Greek document do not gain from beeing marked as another language but still should keep Latin letters as such! Then, the user should still mark the code semantically (as LyX code or whatever), and this semantic markup should take care about the encoding. While this is the reine Lehre, it is often impractical (besides the impossibility to mark inline text as LyX code). * Quite a lot of acronyms are international and will not be hyphenated anyway. * SI unit symbols are international as well. * Short quotes in a language that I do not have installed. It would be misleading to mark e.g. a Vietnamese quote as French in a Greek document, just to prevent it to become Greeeknamese. Also, the current behaviour is unusal in two ways: a) In LyX, I can easily insert Greek or Cyrillic symbols/words in a text written with the Latin or Cyrillic alphabet, this is currently not possible for Latin inside Greek. b) In other Unicode aware programs (as well as with LyX/XeTeX), Latin characters stay Latin even in a Greek context. Practicability beats purity! Günter
Re: Greek text mixed with English
On 2010-03-01, Jürgen Spitzmüller wrote: Guenter Milde wrote: While this is the reine Lehre, it is often impractical. * Quite a lot of acronyms are international and will not be hyphenated anyway. Not true. Why, it is not a contradiction to quite a lot of ... if some.. Acronyms are language-dependent (cf. IPA vs. API). The fact that many acronyms derive from English does not change that. But this is unfair: in a German document, you kan keep the language as German and write RADAR or Laser, in a Greek document, you need to switch langugae (or insert \latintext as ERT) to write Corine. * SI unit symbols are international as well. For SI units, we need markup anyway (in order to use a proper package such as siunitx). But (hopefully) only optional! I prefer to keep control myself. * Short quotes in a language that I do not have installed. It would be misleading to mark e.g. a Vietnamese quote as French in a Greek document, just to prevent it to become Greeeknamese. If you quote Vietnamese, you have to use the Vietnamese language environment. Period. Again, this is very inconvenient. Do you really expect me to become root, install texlive-language-vietnamese (actually first find out the correct name) reconfigure TeX and LyX just to write one Vietnamese word??? Also, the current behaviour is unusal in two ways: a) In LyX, I can easily insert Greek or Cyrillic symbols/words in a text written with the Latin or Cyrillic alphabet, this is currently not possible for Latin inside Greek. That's why we need KeyboardLocaleEncoding support. I agree that the coupling of keyboard locale and text language can be an advancement. It will, however, not help with copy/paste. Also, I find inserting Greek characters by means of the Symbols dialog or by means of copy/paste all but easy. Copy/paste of Greek Unicode is for me not more difficult than copy/paste of English. Inserting via the Symbols dialoge is only an option for the single letter when I don't remember a faster input method (in math, I'd write \alpha ... \omega or use M-G a-o). b) In other Unicode aware programs (as well as with LyX/XeTeX), Latin characters stay Latin even in a Greek context. True. Practicability beats purity! Practicability depends on the user. A user with only a Latin keyboard will find the tranliteration more practical. So do I. A user who uses different keyboard layouts/encodings will find direct input more practical. That's why we need both: a) transliteration as default It could become a non-default option for new documents. b) The normal behaviour (no transliteration if not requested) as option. c) language/encoding switch if the users set up their OS to use keyboard layouts/localizations. This could indeed become the best option for Greek users (and others with multiple keyboard layouts). However, as there is no 1:1 mapping of keyboard layouts and document languages, this power feature needs careful planning to be comprehensible, easy to configure and does not stand in the way. Also, it will not help with existing documents (created in another editor, or taken from the net). This is why we still need b) (unless we force the needy to use XeTeX). I bet people who regularly write Greek and English (have to) do the latter anyway. However, there is more than one way to do this setup... BTW you also need to take backwards compatibility into account. You cannot change the behaviour just like that (without breaking old documents). I do not want to change the rendering of old documents (however, compiling with XeTeX instead of LaTeX or pdflatex will do so). Günter
trunk crash (missing Addsec*)
LyX 2.0.0svn (2009-03-25) crashed on me with: We failed to find the layout 'Addsec*' in the layout list. You MUST investigate! Plain Layout Standard ... Quote Verse --Separator-- lassert.cpp(21): ASSERTION false VIOLATED IN TextClass.cpp:1013 lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help-Introduction and send us a bug report, if necessary. Thanks ! Bye. Abgebrochen when I tried to open DocumentSettings on a file containing \begin_layout Addsec* \series bold Με μια ματιά... \end_layout . Günter
Re: Greek text mixed with English
On 2010-03-02, Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
I just verified that transliteration is still active with XeTeX, so
compiling with XeTeX does _not_ change the rendering of old documents
(if so, I would rate that a XeTeX bug).
Here, (LyX 2.0.0 svn and XeTeX 3.1415926-2.2-0.9995.2 (TeX Live
2009/Debian) I get the following:
* many missing Greek characters (while the Latin ones are preserved)
with the document output set to XeTeX.
* exporting to latex (XeTeX) and compiling by hand:
- the same (without change)
- the same after removing the buggy (and unneeded with XeTeX) \textgreek
definition.
- expected output (Greek as Greek and Latin chars as Latin) after
- \usepackage{babel}
+ \usepackage{polyglossia}
I would rate this a LyX bug.
Günter
Re: Greek text mixed with English
On 2010-03-02, Jürgen Spitzmüller wrote: Guenter Milde wrote: On 2010-03-01, Jürgen Spitzmüller wrote: Guenter Milde wrote: While this is the reine Lehre, it is often impractical. But this is unfair: in a German document, you kan keep the language as German and write RADAR or Laser, in a Greek document, you need to switch langugae (or insert \latintext as ERT) to write Corine. As Nikos explained, he needs to switch the keyboard layout anyway. And of course using two different writing systems is not as easy as using one. However, Nikos started the original thread (months ago) with a 2968 word file imported from somewhere into LyX, stating that he does not want to change all occurences of CORINE, GRASS, GIS, ... into a different language but wants a quick fix for them to be printed in Latin letters. Do you really expect me to become root, install texlive-language-vietnamese (actually first find out the correct name) reconfigure TeX and LyX just to write one Vietnamese word??? Yes. Then we disagree on the weighting of practicability vs. purity. Günter
Re: trunk crash (missing Addsec*)
On 2010-03-02, Jürgen Spitzmüller wrote: Guenter Milde wrote: when I tried to open DocumentSettings on a file containing Could you post this file? Yes. The crash happens in lyx-svn but not in the release version. It disappeared after manually deleting the Addsec* part. Günter #LyX 1.6.5 created this file. For more info see http://www.lyx.org/ \lyxformat 345 \begin_document \begin_header \textclass article \use_default_options false \language german \inputencoding auto \font_roman lmodern \font_sans lmss \font_typewriter lmtt \font_default_family default \font_sc false \font_osf false \font_sf_scale 100 \font_tt_scale 100 \graphics default \paperfontsize default \spacing single \use_hyperref true \pdf_bookmarks true \pdf_bookmarksnumbered false \pdf_bookmarksopen false \pdf_bookmarksopenlevel 1 \pdf_breaklinks false \pdf_pdfborder true \pdf_colorlinks true \pdf_backref section \pdf_pdfusetitle true \papersize a4paper \use_geometry false \use_amsmath 1 \use_esint 1 \cite_engine basic \use_bibtopic false \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \papercolumns 1 \papersides 1 \paperpagestyle default \tracking_changes false \output_changes false \author \author \end_header \begin_body \begin_layout Addsec* \series bold \lang greek Με μια ματιά... \end_layout \begin_layout Itemize \lang greek Λήψη πλακιδίων από τον πανευρωπαϊκό χάρτη CORINE \end_layout \begin_layout Itemize \lang greek Λήψη ακτογραμμών από την διαδικτυακή υπηρεσία του Οργανισμού NOAA coastline extractor \end_layout \begin_layout Itemize \lang greek Δημιουργία τοποθεσίας (LOCATION) στο GRASS βάσει του datum \emph on WGS84 \emph default και εισαγωγή των ακτογραμμών στην βάση δεδομένων \end_layout \begin_layout Itemize \lang greek Επεξεργασία των ακτογραμμών για τη δημιουργία ενός χάρτη-μάσκας που καλύπτει την υπό μελέτη περιοχή \end_layout \end_body \end_document
Re: Greek text mixed with English
On 2010-03-02, Jürgen Spitzmüller wrote:
Guenter Milde wrote:
The following minimal document
-
\documentclass[greek]{article}
\usepackage{fontspec}
\usepackage{babel}
\usepackage{xunicode}
\usepackage{xltxtra}
\begin{document}
test
\end{document}
--
produces a PDF with the string τεστ. This proves that transliteration in
XeTeX works as in (pdf)latex, contrary to your claim.
With babel, yes. As the transliteration is done at the font level (it is
a feature of the LGR font encoding), it cannot be kept for
Unicode-encoded fonts.
However, Greek Unicode chars are missing in the output in the
following example if:
a) babel is included, or
b) the \setmainfont line is commented
\documentclass[greek]{article}
\usepackage{fontspec}
\setmainfont{Gentium}
% \usepackage{babel}
% \usepackage{polyglossia}
\begin{document}
Me mia mati'a...
Με μια ματιά...
\end{document}
Babel selects a different font (the missing unicode support is a
consequence of this font change).
This is one of the reasons why I believe the XeTeX documentation when it
tells that babel and XeTeX are incompatible.
It does not matter whether or not polyglossia does this different than
babel. If you use a different package, you have to be prepared for
such changes
Well, I expect changes with the pdftex - xetex switch, otherwise I would
not switch.
(although I'd say this is a polyglossia bug *if* polyglossia claims to
be a drop-in-replacement for babel [which I don't know].
It is a replacement but not a drop in.
However, if polyglossia changes behaviour, we cannot replace
babel by it anyway, unless the user explicitely requests this.
We must replace babel by polyglossia, as babel is not compatible with
XeTeX. Selecting XeTeX as output machine is an explicite request for
full, language-independent Unicode support.
We might have to care for possible incompatibilities in supported options
and languages with polyglossia, though.
Günter
Re: The emission of \maketitle
On 2010-03-05, Manoj Rajagopalan wrote: Hi lyx-devel, What controls the emission of \maketitle when exporting to latex? There is an intitle (or something like that) keyword for layout styles. It is explained in the Customization guide. (Or look at the implementation of the abstract style.) Günter
Re: Greek text mixed with English
On 2010-03-05, Jürgen Spitzmüller wrote: Guenter Milde wrote: However, Greek Unicode chars are missing in the output in the following example if: a) babel is included, or b) the \setmainfont line is commented ... Please file reports for these. Done. http://www.lyx.org/trac/ticket/6576 I don't think our XeTeX has been thouroughly tested yet. I have implemented it (due to user requests), but I do not use XeTeX myself at all. Thanks for the implementation. Hopefully the upcoming alpha release will get someone with XeTeX experience interested in testing/reporting. We must replace babel by polyglossia, as babel is not compatible with XeTeX. Selecting XeTeX as output machine is an explicite request for full, language-independent Unicode support. Sure, polyglossia support must follow eventually. But this is more work than it seems. You have to dive into our language framework, which is all over the place. But of course, patches are welcome. I am aware of possible problems. Maybe its time I read the XeTeX docs. (I hoped LyX would save me this trouble ;-) Günter
Re: trunk crash (missing Addsec*)
On 2010-03-05, Jürgen Spitzmüller wrote: Guenter Milde wrote: Could you post this file? Yes. Please send an attachment (not inline). Unfortunately, I can't, as I follow the list via Gmane and my slrn newsreader does not support attachments (or I did not find the way how to get this working). Günter
Re: better maxima integration, devel.
On 2010-03-05, Janek Kozicki wrote: rgheck said: (by the date of Fri, 05 Mar 2010 10:18:35 -0500) ... besides improving that communication, the only missing thing is to be able to declare variables within maxima, and operate on them later. It means a running maxima session, instead of standalone/separate calls for each thing. Ideally I would want to derive calculations within lyx, while writing comments about it. All with the beauty of latex. Perhaps I'll start with this communication formatting thing that you explained, it should be an easy start to get feel of the workings. What you are proposing, I think, is somewhat different and looks almost like one of LyX's external insets. ... My sense is that, for full maxima integration, this is definitely the easiest way to go. The disadvantage, compared to the current system, is that there's no integration with the math insets. I see. I would prefer to stay within lyx boundaries. A split window, with the maxima buffer or such. I don't know yet. Storing input in external file is better than putting it into .lyx as comments, I didn't know this is possible. maxima runs well even in a text terminal, it should be possible to pipe this somehow. One more thing to consider is using the lyxserver pipes. E.g. I wrote some experimental LyX output for swiginac (a Python wrapper of the ginac C++ library, http://swiginac.berlios.de/) using my LyXServer Python package (available via the LyX wiki) but the other way is also feasible, as the lyxserver is bidirectional. Günter
Re: Feature request: find-and-replace within selection
On 2010-03-05, Manoj Rajagopalan wrote: It would be useful to support this feature because we could perform a replace-all within a selection and quickly achieve the desired result without clobbering the rest of the document. Agreed. But maybe better making this even more generic: My beloved Jed text editor has a generic narrow feature that limits all editing operations to the current selection until undone by widen. (I think this originates from Emacs.) This could be usefull for spell-checking or other operations as well. Günter
Re: Tabular code question
On 2010-03-11, Vincent van Ravesteijn wrote:
Uwe Stöhr schreef:
I want to fix the vertical alignment bugs in LyX 1.6 and also trunk.
To be able to do this, I need to calculate the height of the content
of the current cell (not the height of the row). How is this done?
Edwin, Abdel, Vincent, do you have any hint for me how this can be done?
tabular.cellInset(cell)-metrics(m, dim);
I assume Uwe wanted the height of the cell content *in the output*,
which might be accessible via a \vphantom{cell-content} command.
There might be side-effects if the cell-content contains macros that
increase a counter (or similar).
Günter
Re: sweave module and custom font issues
On 2010-03-16, Liviu Andronic wrote: --0016e6d99b98aa25240481f389dc Content-Type: text/plain; charset=UTF-8 Dear LyX developers I notice this issue in current SVN (probably Alpha1): 1. open a new 'article' document 2. add the Sweave module 3. write something 4. change Document Fonts Roman to 'Palatino' 5. view pdf 6. the generated pdf will contain the CMR10 A custom font is ignored whenever the Sweave module in included in the document. Would there be a way to work around this? CMR10 (Computer Modern) is the default fallback font if the required font is not available in the requested encoding, shape, family, ... Could you post a minimal tex file (i.e. the result of FileExportpdflatex). Günter
Re: Cleaning some files
On 2010-03-16, Pavel Sanda wrote: - Seminar.txt : Uwe you might want to look at this file and either delete it or add some note into out official manuals? This is a TODO description, obsoleted by seminar.layout since 2002. Günter
Re: sweave module and custom font issues
On 2010-03-18, Liviu Andronic wrote:
--0016e6d7f07bc6fb1e0482107256
Content-Type: text/plain; charset=UTF-8
On 3/18/10, Guenter Milde mi...@users.berlios.de wrote:
Could you post a minimal tex file (i.e. the result of
FileExportpdflatex).
Yes, see attached. Any obvious issues with it?
Some:
1. The code before the preamble prevents error detection.
2. The package Sweave.sty is required, that is not available on CTAN.
3. Searching for Sweave.sty on the net, I found a version with this::
\ifthenelse{\boolean{swe...@ae}}{%
\RequirePackage[T1]{fontenc}
\RequirePackage{ae}
}{}%
which overwrites your font selection with the long deprecated ae
virtual fonts (see l2tabu.pdf).
some solutions:
a) Load the font package after Sweave.sty (e.g. in the LaTeX preamble
with the GUI font selector set to Default).
b) Load Sweave.sty with the noae option.
c) Tell the Sweave.sty maintainer not to load the deprecated package by
default.
Günter
Re: LyX's LaTeX preferences dialog needs quick UI overhaul
On 2010-03-22, Uwe Stöhr wrote: mailarchive is dropping mails and you are probably regularly missing parts of lyx devel communication. In contrary to gmane, mail-archive offers to reply directly to the author of a mail and to sort the mails by date. I read lyx-devel via news.gmane.org and my newsreader allows me all this (reply as mail to the author, sorting by date/thread/author/...) and many more options. Maybe a newsreader would suit your needs too? I nevertheless think it shouldn't be a problem to send the author of a problematic commit a direct email in CC to assure that he reads it. As I am following the list closely, I prefer *not* to get extra copies to my mail address. Others on this list seem to have the same preference, so it is hard to keep track on who wants private mail and who not. Günter
Re: Add Converter via Reconfigure
On 2010-03-23, Jack Desert wrote: It's becoming tedious and error-prone to manually set up file formats and converter definitions for a script I'm writing. How do I automate the process so that the file formats and converter definitions are created when I run Tools -- Reconfigure? This is done by a Python script, configure.py, which you might find and utilize. However, modifying the original would mean that you loose either your variant or any improvements with the next lyx version. Maybe a wrapper (with your extensions and a call to the original) could be designed. (I don't know the details nor whether this is possible at all.) Günter
accents on Cyrillic and Greek chars
Dear LyX developers,
The 'accent-*' LFUNs place a combining Unicode behind the to-be-accented
char and normalize them if possible.
Without normalization, the expansion of combining Unicode chars fails for
Cyrillic and Greek letters.
Example: accent-tilde alpha becomes \~{\textgreek{a}} which places the
accent before the letter.
(For a LyX test file, see http://www.lyx.org/trac/ticket/6463)
For a generic solution, we would need to
* Revert the application of “combining” and “textgreek” features, so
that the accent markup comes inside the \textgreek definition, e.g.
\~{\textgreek{a}} - \textgreek{\~{a}}.
* Remove the braces around the argument for Greek (implemented in trunk)
\textgreek{\~{a}} - \textgreek{\~a}.
Or use a proper accent setup for LGR font encoding
(see http://milde.users.sourceforge.net/ and
http://milde.users.sourceforge.net/lgrenc-accents.def)
For the Greek perispomeni (tilde/circumflex), we could
Define a new LFUN accent-perispomeni (inserting COMBINING GREEK
PERISPOMENI)
resulting in two LFUNS for the same visual effect with different
semantics:
The Greek perispomeni accent
• looks like a tilde,
• has the semantic and etymology of a circumflex accent.
Therefore,
• there is a separate Unicode character, COMBINING GREEK PERISPOMENI (0x0342),
• Greek letter + COMBINING TILDE is not normalized to the corresponding
“... WITH PERISPOMENI” letter.
However,
* in LaTeX, the asciitilde '~' is used for input of both, the tilde
accent and the Greek perispomeni.
* Two LFUNs would also require two keybindings for a ~-accent on either
Greek or non-Greek characters.
This is why I ask for a consensus on how to proceed.
Günter
Re: sweave module and custom font issues
On 2010-03-25, Jean-Marc Lasgouttes wrote:
Jean-Marc Lasgouttes lasgout...@lyx.org writes:
Solution 3: Use \PassOptionToClass. Hmm, it might just work.
I just tried it and it did not work, because
\PassOptionToClass{noae}{Sweave}
is not correct in presence of a \usepackage{/path/to/Sweave} command.
Did you try wiht \PassOptionToPackage?
This must appear *before* the \usepackage call.
Günter
Re: Enhancement bugs for 2.0
On 2010-03-30, Jean-Marc Lasgouttes wrote: Pavel Sanda sa...@lyx.org writes: last call for 2.0 feature requests we have reported. - currently, Sweave reads the files in the encoding of the current locale. This fails as soon as the locale is UTF-8 and the document is 8bit (because the characters themselves are ruined). We need to find a way to pass the encoding to the function. http://www.lyx.org/trac/ticket/6625 I wonder if we could use utf-8 as default latex source encoding for most (all) languages if the locale is UTF-8. Günter
Re: Compile Time
On 2010-04-06, Jack Desert wrote: Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387 MB RAM Compaq Presario, and it takes about 45 minutes. How long should it take? Well, on my Duron 700 with 512 MB, it took several hours (and finally crashed). You can save memory/time if you compile without debugging info:: Ohne debug-symbole, mit suffix (lyx - lyx-svn):: ./configure --with-version-suffix=-svn --enable-build-type=release and then * make, make install Günter
Re: edit ERT insets with external editor?
On 2010-04-01, rgheck wrote: On 04/01/2010 04:41 AM, Abdelrazak Younes wrote: On 03/31/2010 05:53 PM, Liviu Andronic wrote: Dear LyX developers Would it be a good idea to allow users to edit ERT insets with an external editor? [snip] It is a good idea but it sounds a bit complicated to implement for the communication of the child process; but it doable. Couldn't we do this internally, fairly easily? We already have LaTeX highlighting in the preamble. Most users that use complex ERT * will be familiar with LaTeX, * will have a favourite LaTeX editor. Reproducing the favourite LaTeX editors in LyX will never reach near the original. Günter
Re: Enhancement bugs for 2.0
On 2010-04-01, Jean-Marc Lasgouttes wrote: Le 31/03/2010 13:07, Guenter Milde a écrit : I wonder if we could use utf-8 as default latex source encoding for most (all) languages if the locale is UTF-8. AFAIK, UTF8 support is too weak in LaTeX right now. While it is weak in LaTeX, LyX's own UTF8 support is fine and also kicks in if the latex-source is in UTF-8. In a modern system, it really does not make sense to write the source in iso8859-15, say, if the locale is UTF-8. And people should be able to chose the encoding they want. Of course they should. However, this is not prevented by using a different *default*. Günter
Re: LyX 1.6.6: please prepare for landing
On 2010-04-05, Jürgen Spitzmüller wrote:
Translation updates and patches should be submitted *no later* than Friday,
April 23.
Please apply the following patches to fix/clean up the Greek language
support:
http://www.lyx.org/trac/attachment/ticket/6456/languages-polutonikogreek-branch.patch
to fix bug http://www.lyx.org/trac/ticket/6456.
http://www.lyx.org/trac/attachment/ticket/6458/LaTeXFeatures-greektext.patch
to fix bug http://www.lyx.org/trac/ticket/6458
Some comments to the second patch:
static docstring const textgreek_def = from_ascii(
- \\providecommand*{\\perispomeni}{\\char126}\n
- \\AtBeginDocument{\\DeclareRobustCommand{\\greektext}{%\n
- \\fontencoding{LGR}\\selectfont\\def\\encodingdefault{LGR}\n
- \\renewcommand{\\~}{\\perispomeni}\n
- }}\n
+ \\DeclareRobustCommand{\\greektext}{%\n
+ \\fontencoding{LGR}\\selectfont\\def\\encodingdefault{LGR}}\n
\\DeclareRobustCommand{\\textgreek}[1]{\\leavevmode{\\greektext #1}}\n
The old implementation overwrites the \textgreek definition from
babel with a custom version adding a re-definition of the \~ macro with
the side-effects for Greek documents described in bug 6458 and shown in
http://www.lyx.org/trac/attachment/ticket/6458/accent-tilde-in-greek-document-minimal.lyx
.
This patch brings the \textgreek definition in line with the version
provided by the 'babel' package.
Instead, the re-definition of the \~ is done
* outside the \textgreek definition, but
* local to the LGR font encoding,
so other alphabets are not affected:
- \\DeclareFontEncoding{LGR}{}{}\n);
+ \\DeclareFontEncoding{LGR}{}{}\n
+ \\DeclareTextSymbol{\\~}{LGR}{126});
Both, the current implementation and the proposed patch
* support Greek unicode characters via the definitions in unicodesymbols
independent of the document and/or text language.
* overwrite the \~ (tilde text accent) LaTeX macro so that placing a
tilde (perispomeni) accent on Greek characters is only possible for the
characters which in Greek orthography take such an accent. For other
characters the tilde is placed in front of the character.
This is the price we have to pay for the support of proper typesetting
of the multi-accented characters like ἆ (GREEK SMALL LETTER ALPHA WITH
PSILI AND PERISPOMENI).
The patch restricts this re-definition to characters of the Greek
alphabet (as opposed to any character in a Greek document).
As the accent-tilde lfun does not work properly with Greek characters
(except for text in polytonic Greek) anyway (see Bug #6463), this is
a tolerable restriction.
BTW: the right way would be to properly define the \~ text accent
macro for the LGR font encoding as in
http://milde.users.sourceforge.net/lgrenc-accents.def
.
Günter
Re: LyX 1.6.6: please prepare for landing
On 2010-04-09, Jürgen Spitzmüller wrote: Pavel Sanda wrote: I prefer to apply all those changes to trunk first, let them be tested you are probably the one to commit it? Done: http://www.lyx.org/trac/changeset/34099 http://www.lyx.org/trac/changeset/34100 Günter, please check if everything is in place now. Yes, thanks, Günter
Re: posible bug: url and percentage
On 2010-04-13, Fox_Van wrote: --001636e0a5ac84c7de0484265273 Content-Type: text/plain; charset=ISO-8859-1 Working on a document I put a url tag inside a footnote and then the document did not exported to PDF anymore, but DVI does with not working references This is the case: *FOOTNOTE[* Making R Packages Under Windows: A Tutorial. *URL[* http://faculty.chicagobooth.edu/peter.rossi/research/bayes%20book/bayesm/Making%20R%20Packages%20Under%20Windows.pdf ]* ]* When I removed the percentage symbols everything worked correctly. I did not found any related ticket on trac. If a string contains any %, #, or ^^, or ends with ``\``, it can't be used in the argument to another command. The argument must not contain unbalanced braces. We need to escape #, \, and % if we use the URL in a command. This is done with InsertHyperref but not with InsertURL (tested with LyX 2.0) If using hyperref is not an option, escape the % with a backslash:: http://example.org/bayes\%20book/ Günter
Re: result of a first test with LyX 2.0alpha2
On 2010-04-19, Enrico Forestieri wrote: On Mon, Apr 19, 2010 at 02:14:25AM +0200, Vincent van Ravesteijn wrote: Uwe Stöhr schreef: There is room for improvement here, Enrico ? Maybe the alert dialog could be redesigned for accepting 4 buttons instead of 3, such that to avoid the need for further asking whether one wants to overwrite all. But I am not the one which is going to do that. I am still missing an option to rename either the existing or the new file. Günter
LyX leaves empty file index in pwd
Dear LyXers, since some time, I find strange files named index with no content here and there in my directories. Today I examined the problem and found out that my LyX (LyX 1.6.5 (2009-12-05) from the Debian/testing package) leaves them behind in the working directory. How to reproduce: * go to a test directory * open LyX * close LyX * list the files (e.g. `ls -l`) Anyone else sees this problem? It does not occur with my home-compiled LyX 2.0.0svn. Günter Günter
Re: Problem using tex2lyx Unicode char \u8:�in not set up for use with LaTeX.
On 2010-05-22, Niklaus Giger wrote: ... But when I tried to import all the files from https://elexis.svn.sourceforge.net/svnroot/elexis/trunk/doc_fr I did run into several problems: ... b) When converting to PDF via pdflatex I ran into several problems: b1) (a lot of them) wrong input encoding: ! Package inputenc Error: Unicode char \u8:=EF=BF=BDin not set up for use w= ith LaTeX. The standard unicode input encoding (utf8) is rather limited. LyX has a more comprehensive translation table, so setting the output encoding to language default (in DocumentSettingsLanguage) might solve this problem. Günter
Re: Python 3
On 2010-05-26, José Matos wrote: On Wednesday 26 May 2010 15:29:13 Pavel Sanda wrote: can you be even more verbose abou the subtle problems? my imagination was that there exists pythonic code running under both 2 3 so once we convert the code we dont need to care anymore about versioning... What would it be the minimum version required on the 2.x side? Currently we support from 2.3.4 up to the latest 2.7 beta It is more or less easy to have running code for python 2.6 and 3.1, the further down you go to older version the difficult it comes. For code that should work with both Python 2 and 3, the Python docs recommend maintaining a Python-2 version and auto-converting to Python-3 code with the 2to3.py script. This can be made part of the install routine, e.g. in a setup.py script. One example in python 2.x 5/2 == 2 on python 3.x you get 5/2 == 2.5 (as much as equality tests are appropriate for floating point operations) Another tricky point (and more important for the LyX Python scripts) is the 8-bit vs. Unicode nature of strings: In Python 2, strings are 8-bit, unless explicitely converted to Unicode (with the .decode() method) or given as usomething string literal. In Python 3, strings are Unicode, unless explicitely converted to binary or givne as bsomething string literal. Hence, reading a file will result in a binary string in Python 2 and a Unicode string in Python 3 which brings subtle problems especially with error handling. My conclusion: it can be done, however it is a burden we should only take on if really necessary. To me, it seems that most systems still have a 2.x version available. Günter
Re: Problem using tex2lyx Unicode char \u8:�in not set up for use with LaTeX.
On 2010-05-27, Jean-Marc Lasgouttes wrote: b) When converting to PDF via pdflatex I ran into several problems: b1) (a lot of them) wrong input encoding: ! Package inputenc Error: Unicode char \u8:=EF=BF=BDin not set up for use w= ith LaTeX. The standard unicode input encoding (utf8) is rather limited. LyX has a more comprehensive translation table, so setting the output encoding to language default (in DocumentSettingsLanguage) might solve this problem. However the question is to know why the encoding is set to utf8 by tex2lyx. Most probably because the original file used it. However, in this case the question is, how the non-translable Unicode character came into the file: * Does tex2lyx do reverse engineering of LaTeX commands to unicode characters? * or, maybe the OP did insert it after the conversion to LyX? A minimal example file would help. Günter
Re: spreadsheet capability?
On 2010-05-28, xPol wrote: Has anybody ever tried to provide lyx with some spreadsheet capability, exploiting its symbolic computation backends? Not to my knowledge. However, the Gnumeric spreadsheet has a LaTeX export feature, so one could possibly write an external inset wrapper for it. Günter
Re: Stix fonts are out!
On 2010-05-31, Jean-Marc LASGOUTTES wrote: Manoj Rajagopalan rma...@umich.edu writes: Hi lyx developers, Just thought this news would interest you. From the stixfonts.org: It is definitely interesting. I am not sure that we should rush on them now. Maybe wait a bit until they get into texlive and friends. Actually, there is no TeX support yet, so they are only usable with XeTeX for now (unless someone step in). Also, the math-tables are missing, hence math will not work with XeTeX out-of-the box either. Günter
Re: show the lyx code (was: feature proposal: show latex code: allow to manipulate the latex code: reveal code)
On 2010-06-07, Pavel Sanda wrote: Vincent van Ravesteijn wrote: what looks much easier is to allow mutating math environment into ERT and back. pavel This is already possible. It needs some copy-pasting but it works. I once implemented this, but then disregarded it because it was essentially already possible. i know, but that needs some understanding how our math insets works and its uncomfortable to do. It is quite simple and in line with other insets: * Backspace at the first position in the inset converts it to normal text (in this case LaTeX code (without beeing marked as ERT)) Now edit ... * Highlight and Ctrl-M converts it back to a Math inset. If all you want is simple editing, there is no urgent need to have it as ERT in the meantime. i was talking about something like Switch to ERT/Math item in context menu so even normal users get the idea... OK, I see 2 advantages: 1. no need to place the cursor or highlight 2. you can compile while the Math is editible (as ERT) that might offset the cost of added complexity. Günter
Re: show the lyx code (was: feature proposal: show latex code: allow to manipulate the latex code: reveal code)
On 2010-06-07, Pavel Sanda wrote: Guenter Milde wrote: * Backspace at the first position in the inset converts it to normal text (in this case LaTeX code (without beeing marked as ERT)) not in math inset. Sorry, then this is a feature request. OK, I see 2 advantages: 1. no need to place the cursor or highlight thats what i call uncomfortable. Agreed. Günter
Re: r34591 - in lyx-devel/trunk: lib/scripts src src/insets src/tex2lyx
On 2010-06-08, José Matos wrote: On the same vein as your work and since I dislike the latex output of lyx- beamer I have a workaround in the form of a python script and another layout. Did already you consider using custom insets for the frames? I started doing this for the seminar.layout. This easily translates to the way these environments are used in LaTeX. Unfortunately, there is no easy obsoleting a Layout with an Inset. Günter
Re: XML format status
On 2010-06-08, Sam Liddicott wrote: This is a multi-part message in MIME format. --050502020101020702060201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/06/10 15:27, Pavel Sanda wrote: Sam Liddicott wrote: I also still dream about lyx being the first decent docbook editor. are you aware of the fact that lyx already have output routines for docbook? Yes, but I recall being told that it wasn't supported and that if it still worked it was pretty much by good luck these days. If that is no longer true, I'd be glad to know! It is still true. OTOH, native XHTML output is brand new (LyX 2) and actively worked on, so you might give it a try. Günter
Re: Navigate to last paragraph of section
On 2010-06-14, Rob Oakes wrote: Specifically, I'd like to create an LFUN that allows me to quickly place = the cursor at the end of the last paragraph of the current section = (e.g., the paragraph before another section at the same toclevel). I = initially thought that I could use some of the outline code to locate = the last paragraph in the section, and then use the LFUN_PARAGRAPH_GOTO = function to get me there. I would suggest to jump to the next section and then one paragraph up. If there is no next section, goto end-of-document instead. Günter
Re: [patch] layout dependencies
On 2010-07-30, Julien Rioux wrote: This is a multi-part message in MIME format. --030503040800070104030405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi LyX developers, LyX 2.0 now has a new mechanism for relaying layout dependencies to the user, such as the class filename. Most LaTeX classes also rely on certain packages to be installed. It could be argued that this information should be provided to LyX in the layout files. This patch address this. With these additions, it would be nice if the reported error for nonavailable dependencies would be changed from Not available: to Missing dependencies: ... Günter
Re: FAQ
On 2010-08-13, Jürgen Spitzmüller wrote: Paul A. Rubin wrote: Can we define a criterion for outdated? And should attempt to fix it or delete it? ... (I would vote for the latter, but I'm not entirely comfortable about deleting someone else's entries. If I find something I myself posted that is obsolete, I'll cheerfully recycle the bytes.) The wiki is a collaborative tool. If we hesitate to correct, edit and probably also remove other peoples entires, the wiki ends up as an ecclectic piece of text which helps nobody. Remember that the history of the pages is available to all (with some extra clicks), so if you delete some obsolete info, it is not completely lost and people insisting on using old versions can still get the help by checking old versions of the wiki. (Maybe we could make this clear in an intro page.) Günter
Re: short cuts: fonts in math mode
From the users list... On 2010-08-13, Paul A. Rubin wrote: On 8/12/2010 6:22 PM, Uwe Stöhr wrote: There are already some shortcuts. Highlight some parts of your formula and then press Alt+c and then r. This leads to upright characters (\mathrm). Alt+c and c gives for example \mathbb. After typing Alt+c the LyX status bar will show you the available characters connected to the Alt+c shortcut. For more shortcuts have a look at the LyX menu Tools-Preferences-Editing-Shortcuts. This is very useful to know but not visible in the Tools ... Shortcuts dialog. (If you filter on Alt+C, only boldsymbol and roman appear, and the user has to recognize that roman implies \mathrm in math mode.) I've filed an enhancement ticket to add the relevant options to the Mathematical Symbols section of Tools ... Shortcuts, and in the interim I put a table of shortcuts in the wiki (http://wiki.lyx.org/LyX/MathInLyX#toc4). I suppose this mapping of text-font to math-font is hardcoded somewhere (invisible to non-developers) for ages (predating command-alternatives). Could this be re-defined using command-alternatives? Günter
Re: Typing in LyX extremely slow / produced high X server load
On 2010-08-20, Rainer Dorsch wrote: Am Freitag, 20. August 2010 schrieb Paul Johnson: On Fri, Aug 20, 2010 at 12:09 PM, Rainer Dorsch rdor...@web.de wrote: I noticed that typing in LyX sometimes becomes incredibly slow (it takes approximately 1s per character). top shows in these cases a very high Xserver load: I think LyX was a victim not the root cause, I found in my Xorg.0.log file: [mi] EQ overflowing. The server is probably stuck in an infinite loop. ... Not sure what is causing that, but that does not look goodI disabled kwin effects (KDE4) now, hoping that this removes enough stress from the X server that I do not see the EQ overflowing often anymore. I once had a similar problem due to bad interaction with the clipboard manager. Do you use klipboard? What happens if you disable it? Just a guess... Günter
Re: what does the local layout in the document settings do?
On 2010-08-30, Uwe Stöhr wrote: What exactly does the local layout feature in the document settings? It is in the document settings now? Then this is an interface to the hithere hidden possibility to include a layout with a document. I tried to use it but don't understand how it works. Here are my annotations and bug reports: ... - I found out that I can define there snippets of layout files. As test I copied this into the local layout field: Style Affiliation ... I can then use this style but this will of course cause LaTeX errors, because the document class is still article and article doesn't provide \affiliation. But LyX tells the user that the format is valid. This is confusing. Think of local layouts as an analogy to the LaTeX preamble. It is a power user feature. The user must make sure that the used LaTeX macros are supported. Günter
Re: lilybook module
On 2010-08-31, Julien Rioux wrote: On 31/08/2010 3:35 PM, Guenter Milde wrote: On 2010-08-30, Jean-Marc Lasgouttes wrote: Using the OutputFormat tag defined for use with sweave, one can have a module that changes the format (and thus add an extra convert step). ... Could this be used to allow LilyPond source code in LyX that is converted to musical scores by the 'lilypond-book' pre-processor? Yes, I have already submitted a patch to this list to implement it. Once again, there is a thread on the user list requesting this feature, so I hope it can go e.g. to the Wiki. Since then I have worked on the patch a little bit. It works well except for one or two things. As mentioned in a previous message in this tread, instant preview always treats the current buffer as LaTeX, so any attempt to change the OutputFormat to allow preprocessing by lilypond-book is ignored by the preview mechanism. My current fix to get Instant preview working is kind of a hack, so I haven't posted a updated patch yet. For me, it would be OK to typeset the LilyPond code verbatim in the instant preview with a macro redefinition in the preamble that gets removed/replaced by the pre-processor. I agree this is not WYSIWYG but an instant fallback solution. Günter
Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
On 2010-10-21, Vincent van Ravesteijn wrote: but now we have new problem - how to notice user that exporting is stillbr= in progress or finished (some subvserion of hourglass cursor?).br Status bar: Moving icons. Text. Messages. greyed out (or otherwise modified) export toolbar buttons? Günter
Re: Improvements to Recover Emergency File prompts. (pseudo-patch with discussion)
On 2010-10-25, Richard Heck wrote:
On 10/25/2010 01:23 PM, John McCabe-Dansted wrote:
On Tue, Oct 26, 2010 at 12:03 AM, Richard Heckrgh...@comcast.net wrote:
+e.checksum() != s.checksum()) {
There are a number of ways to get a dirty buffer without actually
changing the file. E.g we can add two spaces that get converted to a
single space, or we can add a character and then remove it by
backspacing. This seems to happen fairly regularly to me, so it seems
worth checking for.
I'm not sure where this code is. I'd want to see the context before deciding
whether this is worth it.
It occurs immediately prior to prompting the user whether we want to
open the original or the emergency file. I consider it worthwhile
since even IO is cheap compared to user time (and user concentration).
OK. Does anyone else have a view about this?
I'd like this test also before the save buffer? popup when closing LyX.
(Currently, even change-something; undo will trigger this prompt.)
Günter
Re: crash with trunk
On 2010-11-19, Guenter Milde wrote: trying to test LyX (trunk), I updated my repository with `git svn rebase` and compiled. (On a Debian/testing 64-bit system.) However, even the simple Ctrl-N (open new buffer) leads to a crash: Program received signal SIGSEGV, Segmentation fault. 0x00529dd9 in lyx::Counters::reset() () The problem vanished after make distclean followed by an sources update and a new build... Günter
Re: [patch] fix bug 3008
On 2010-11-19, Georg Baum wrote:
Hi,
after I needed to explain several times lately why one should not use the
menu entries for sub/superscript in text and what to do instead, I finally
sat down and completed a fix for bug 3008 that I started years ago. It
implements a new inset for subscript and superscript in text mode, including
correct output for all backends. There are some other ideas discussed in
http://www.lyx.org/trac/ticket/3008, but the inset approach is the best one
IMO.
...
+# these classes provide a \textsubscript command:
+# FIXME: Would be nice if we could use the information of the .layout
file here
+classes = [memoir, scrartcl, scrbook, scrlttr2, scrreprt]
+if foundsubscript and find_token_exact(classes, document.textclass, 0)
== -1:
+add_to_preamble(document, ['\\usepackage{subscript}'])
Please use the fixltx2e package for \textsubscript:
Provides a command \textsubscript , which is a modified version the
command \textsuperscript that's part of LaTeX. The command is also
(now) provided by the fixltx2e package distributed with LaTeX itself;
if you are running a LaTeX distribution no earlier than 2005/12/01, you
will have a more satisfactory means of using the command.
-- http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=subscript
I argue, that LyX-2 should by default *always* insert
\usepackage{fixltx2e}. This package collects a range of fixes and
improvements that are not not in the LaTeX core due to backwards
compatibility issues. The quantum-leap from 1 to 2 would be a good
place for this change:
Identifierfixltx2e
Caption Patches for LaTeX.
Description
LaTeX policy is that things should not change, between releases, in a
way that will cause incompatibility with old documents, or will cause
typesetting of an unchanged document to change.
Nevertheless, there are problems in LaTeX that it “would be nice” to
correct; fixltx2e provides a home for these corrections. Corrections
in the current version are:
* ensure one-column floats don't get ahead of two-column floats;
* correct page headers in twocolumn documents;
* stop spaces disappearing in moving arguments;
* allowing \fnysmbol to use text symbols;
* allow the first word after a float to hyphenate;
* \emph can produce caps/small caps text;
* bugs in \setlength and flushbottom.
-- http://tug.ctan.org/pkg/fixltx2e
Günter
Re: [patch] fix bug 3008
On 2010-11-22, Uwe Stöhr wrote:
On 21/11/2010 5:20 PM, Uwe Stöhr wrote:
That it is not included in MiKTeX, also not via the fragments or
fixltx2e package. Therefore all LyX on Windows would be forced to
install the file manually which is not acceptable.
How about using
\usepackage{fixltx2e}
for providing \textsubscript? This one is shipped with miktex.
As I said (you even cited this) fixltx2e is not available for MiKTeX,
at last not under MiKTeX 2.9.
This would be very strange:
The package is distributed as part of LaTeX; the extracted package is
also available on the archive (location linked here).
-- http://www.ctan.org/tex-archive/help/Catalogue/entries/fixltx2e.html
I suppose it is not mentioned as extra download/extension because it
is already part of every latex base install.
Günter
Re: [patch] LuaTeX
On 2010-11-22, Jürgen Spitzmüller wrote: Pavel Sanda wrote: * why do we want it at all - or in more general, what are we aiming to support? all pdftex, xetex, luatex? Yes. Seconded. ... pdftex is very stable and reliable, and for people who do not need all the nifty new features, there's no need to depart from pdftex, neither to XeTeX nor to LuaTeX. and while more and more packages are made unicode ready, pdftex is the save bet. XeTeX is completely orthogonal to LuaTeX, although there are shared aims. ... From a user POV, both provide OpenType and true Unicode support, but they also have their respective strengthes and weaknesses: ... I guess it is fair to support either of these backend. Especially as there is active work to have a common LaTeX interface, e.g. hyperref, fontspec and unicode-math are all updated to work with both engines (hyperref also with pdftex), polyglossia will follow. Günter
Re: [patch] LuaTeX
On 2010-11-22, Richard Heck wrote: On 11/22/2010 10:55 AM, Jürgen Spitzmüller wrote: Out of curiosity, I checked out what it would need us to implement basic support for Lua(La)TeX (basic in the sense of what we had for XeTeX prior to the polyglossia commit today*). And it's really as simple as the attached. What I would do additionally to the patch are just two cosmetic things: (1) rename the buffer param useXeTeX to useLuaXeTeX (or something else, if someone comes up with a better name), since that param just tells us that we use a modern utf8- and OpenType-aware processor (such as XeTeX and LuaTeX), contrary to the flavour that tells us which processor this is. This one would be a file format change, although a very simple one. useUnicodeTeX? useUTF8TeX? useUniTex? (2) In the GUI, I would rename the Use XeTeX checkbox to Use System Fonts (since this is really what is of interest for the end user) and put the checkbox to fonts. Rather not: * The reason to use XeTeX/LuaTeX can also be a craving for better Unicode support (e.g. Latin words in a Greek document without the need to set the language, support for more Unicode characters like e.g. Block Elements). * XeTeX can also use OpenType fonts that are not system-wide installed as well as traditional LaTeX fonts. This one I'm less sure about. I cant tell from the patch how we decide which one to use. Wasn't it determined before by the Use XeTeX box? Anyway, clearly I'm confused. There should be no need to have separate XeTeX and LuaTeX settings. IMV, it is also wrong to define the used engine as a special document setting: Just like we allow export of the same document to XHTML, PS, and PDF without change in the document settings, we should allow * PDF (ps2pdf) * PDF (pslatex) * PDF (xetex) * PDF (luatex) as export options. This would also mean that there should be the possibility to configure font sets for pdftex, xetex/luates, and html in parallel in one document. I suppose it is too late to change this for 2.0, though. Currently, you would need to set the LaTeX - PDF (UniTeX) converter to either xetex or luatex. Günter
