From: G. M. <g....@qu...> - 2007-02-26 10:32:06
|
Dear docutillers, trying to export a document containing a greek "mu", I faced the following problem. Minimal example:: A layer of 2 µm PZT ... is translated by rst2latex to:: A layer of 2 µm PZT ... Running pdflatex on this produces:: ! Missing $ inserted. <inserted text> $ l.69 A layer of 2 µ m PZT ... ? ! Emergency stop. (pdf)latex expects the µ in math-mode, as the inputenc package (\usepackage[latin1]{inputenc}) translates it to the math command \mu A save export variant that is still quite readable would be:: A layer of 2 \ensuremath{µ}m PZT ... (taken from the LaTeX export option of LyX). Is there a way to extend the rst2latex writer to wrap greek letters into an ``\ensuremath`` command? BTW: the problem is solved in rst2newlatex via:: \DNparagraph{% A{ }layer{ }of{ }2{ }$\mathrm{\mu}$m{ }PZT{ }...% }% so, maybe the detection-logig is already there. Günter |
From: <gr...@us...> - 2007-02-26 11:13:15
|
> trying to export a document containing a greek "mu", I faced the followin= g > problem. > > Minimal example:: > > A layer of 2 =B5m PZT ... > > > is translated by rst2latex to:: > > A layer of 2 =B5m PZT ... > > Running pdflatex on this produces:: > > ! Missing $ inserted. > <inserted text> > $ > l.69 A layer of 2 =B5 > m PZT ... > ? > ! Emergency stop. > > (pdf)latex expects the =B5 in math-mode, as the inputenc package > (\usepackage[latin1]{inputenc}) translates it to the math command \mu what about using latex unicode package ? > A save export variant that is still quite readable would be:: > > A layer of 2 \ensuremath{=B5}m PZT ... > > (taken from the LaTeX export option of LyX). > > Is there a way to extend the rst2latex writer to wrap greek letters into = an > ``\ensuremath`` command? i think it is, if it is necessary (e.g. latex unicode not usable ?) cheers --=20 |
From: Riccardo M. <ric...@gm...> - 2007-02-26 11:43:00
|
T24gMi8yNi8wNywgRy4gTWlsZGUgPGcubWlsZGVAcXVhbnRlbnR1bm5lbC5kZT4gd3JvdGU6Cj4g RGVhciBkb2N1dGlsbGVycywKPgo+IHRyeWluZyB0byBleHBvcnQgYSBkb2N1bWVudCBjb250YWlu aW5nIGEgZ3JlZWsgIm11IiwgSSBmYWNlZCB0aGUgZm9sbG93aW5nCj4gcHJvYmxlbS4KPgo+IE1p bmltYWwgZXhhbXBsZTo6Cj4KPiAgIEEgbGF5ZXIgb2YgMiDCtW0gUFpUIC4uLgo+Cj4KPiBpcyB0 cmFuc2xhdGVkIGJ5IHJzdDJsYXRleCB0bzo6Cj4KPiAgIEEgbGF5ZXIgb2YgMiDCtW0gUFpUIC4u Lgo+Cj4gUnVubmluZyBwZGZsYXRleCBvbiB0aGlzIHByb2R1Y2VzOjoKPgo+ICAgISBNaXNzaW5n ICQgaW5zZXJ0ZWQuCj4gICA8aW5zZXJ0ZWQgdGV4dD4KPiAgICAgICAgICAgICAgICAgICAkCj4g ICBsLjY5IEEgbGF5ZXIgb2YgMiDCtQo+ICAgICAgICAgICAgICAgICAgICAgIG0gUFpUIC4uLgo+ ICAgPwo+ICAgISBFbWVyZ2VuY3kgc3RvcC4KPgo+IChwZGYpbGF0ZXggZXhwZWN0cyB0aGUgwrUg aW4gbWF0aC1tb2RlLCBhcyB0aGUgaW5wdXRlbmMgcGFja2FnZQo+IChcdXNlcGFja2FnZVtsYXRp bjFde2lucHV0ZW5jfSkgdHJhbnNsYXRlcyBpdCB0byB0aGUgbWF0aCBjb21tYW5kIFxtdQo+CgpJ J3ZlIHRyaWVkIHRvIHVzZSBVVEYtOCBhbmQgcnN0MmxhdGV4LCBidXQgaXQgdHVybmVkIG91dCBo YXJkZXIKdGhhbiBJIHRob3VnaHQuICBGaXJzdCBvZiBhbGwsIHJzdDJsYXRleCB3cml0ZXMKYFx1 c2VwYWNrYWdlW2xhdGluMV17aW5wdXRlbmN9YCBpbiB0aGUgTGFUZVggc291cmNlIGV2ZW4gaW4g dGhlIGZhY2UKb2YgYSBVVEYtOCBiYXNlZCBsb2NhbGUgYW5kIGAtLW91dHB1dC1lbmNvZGluZz11 dGYtOGAuCgpUaGlzIGlzIGVhc3kgdG8gcGF0Y2g6OgoKLS0tIHkudGV4Lm9yaWcJMjAwNy0wMi0y NiAxMjoyNjo1MC43Nzc5MzMxODYgKzAxMDAKKysrIHkudGV4CTIwMDctMDItMjYgMTI6MTc6Mzgu ODYwNDUzMDc0ICswMTAwCkBAIC0xLDkgKzEsOCBAQAogXGRvY3VtZW50Y2xhc3NbMTBwdCxhNHBh cGVyLGVuZ2xpc2hde2FydGljbGV9Ci1cdXNlcGFja2FnZXtiYWJlbH0KIFx1c2VwYWNrYWdle2Fl fQogXHVzZXBhY2thZ2V7YWVndWlsbH0KIFx1c2VwYWNrYWdle3Nob3J0dnJifQotXHVzZXBhY2th Z2VbdXRmOF17aW5wdXRlbmN9CitcdXNlcGFja2FnZVtlbmdsaXNoLGdyZWVrXXtiYWJlbH0KK1x1 c2VwYWNrYWdle3Vjc30KK1x1c2VwYWNrYWdlW3V0Zjh4XXtpbnB1dGVuY30KIFx1c2VwYWNrYWdl e3RhYnVsYXJ4fQogXHVzZXBhY2thZ2V7bG9uZ3RhYmxlfQogXHNldGxlbmd0aHtcZXh0cmFyb3do ZWlnaHR9ezJwdH0KClRoYXQgaXMsIHJlcGxhY2UgbGluZXM6OgoKICBcdXNlcGFja2FnZXtiYWJl bH0KICAuLi4KICBcdXNlcGFja2FnZVt1dGY4XXtpbnB1dGVuY30KCndpdGggbGluZXM6OgoKICBc dXNlcGFja2FnZVtlbmdsaXNoLGdyZWVrXXtiYWJlbH0KICBcdXNlcGFja2FnZXt1Y3N9CiAgXHVz ZXBhY2thZ2VbdXRmOHhde2lucHV0ZW5jfQoKTm93LCB0aGUgYHV0Zjh4YCBMYVRlWCBpbnB1dCBl bmNvZGluZyB3aWxsIGRlZmluZSB0aGUgY2hhcmFjdGVyIM68IHRvCnJ1biB0aGUgYFx0ZXh0bXVg CmNvbW1hbmQsIHdoaWNoIG5lZWRzIHRoZSBHcmVlayBmb250cyAoZm9udGVuYyBMR1IpOyBpZiB5 b3Ugd2FudCB0byBtaXgKdGhpcyB3aXRoIEVuZ2xpc2ggdGV4dCAoZm9udGVuYyBPVDEgb3IgVDEp LCB5b3Ugc2hvdWxkIHdyYXAgdGhlIEdyZWVrCmxldHRlcnMgaW4gYSBge1xncmVla3RleHQgLi4u fWAgYmxvY2suICBUaGUgc2ltcGxlc3Qgd2F5IEkgZm91bmQgdG8gZG8KdGhpcyBhdXRvbWF0aWNh bGx5IGlzOgoKLS0tIHkudGV4Lm9yaWcJMjAwNy0wMi0yNiAxMjoyNjo1MC43Nzc5MzMxODYgKzAx MDAKKysrIHkudGV4CTIwMDctMDItMjYgMTI6MTc6MzguODYwNDUzMDc0ICswMTAwCkBAIC02Myw2 ICs2Miw5IEBACgogXHNldGxlbmd0aHtcbG9jYWxsaW5ld2lkdGh9e1xsaW5ld2lkdGh9CgorXGxl dFx1Y3N0ZXh0bXU9XHRleHRtdSUgc2F2ZSB1Y3Mgb3JpZ2luYWwgZGVmaW5pdGlvbgorXHJlbmV3 Y29tbWFuZFx0ZXh0bXV7e1xncmVla3RleHRcdWNzdGV4dG11fX0lIGFsbG93IGZyZWVseSBtaXhp bmcKd2l0aCBFbmdsaXNoIHRleHQKK1xzZWxlY3RsYW5ndWFnZXtlbmdsaXNofSUKIEEgbGF5ZXIg b2YgMiDOvG0gUFpUIC4uLgoKIFxlbmR7ZG9jdW1lbnR9CgpUaGF0IGlzLCByZWRlZmluZSBjb21t YW5kIGBcdGV4dG11YCB0byBydW4gYHtcZ3JlZWt0ZXh0XHVjc3RleG11fWAsCndoZXJlIGBcdWNz dGV4dG11YCBpcyB0aGUgb3JpZ2luYWwgZGVmaW5pdGlvbiBmcm9tIHBhY2thZ2UgYHVjc2AuCgpX aXRoIGEgbGl0dGxlIE1ha2VmaWxlIG9yIHNoZWxsIHNjcmlwdGluZywgeW91IGNhbiBoYXZlIGBw YXRjaGAgZG8KdGhpcyBmb3IgeW91LiAgVGhlcmUgbWlnaHQgYmUgYSB3YXkgdG8gZW5jb2RlIHRo aXMgaW4gcmVTVCB3aXRoCnJhdy1iYXNlZCByb2xlcywgYnV0IEkgaGF2ZSBubyBleHBlcmllbmNl IHdpdGggdGhhdC4KCk1vcmUgaW5mbyBvbiB0aGUgTGFUZVggdW5pY29kZSBwYWNrYWdlOgoKICBo dHRwOi8vd3d3LnVucnVoLmRlL0RuaVEvbGF0ZXgvdW5pY29kZS8KCmFuZCBwYXJ0aWN1bGFybHkg KHRob3VnaCBhIGJpdCBvdXRkYXRlZCBpbiB0aGUgZXhhbXBsZXMpOgoKICBodHRwOi8vd3d3LnVu cnVoLmRlL0RuaVEvbGF0ZXgvdW5pY29kZS91Y3MvbGFuZ3VhZ2VzLnBzLmd6CgoKQWJvdXQgcnN0 Mm5ld2xhdGV4IHNvbHV0aW9uOiBpdCB3aWxsIHRyYW5zbGF0ZSDOvCB0byBgJFxtdSRgLiAgTm8g bW9yZQplcnJvcnMsIGJ1dCB0aGUgdHlwb2dyYXBoaWNhbCByZW5kZXJpbmcgaXMgaW5jb3JyZWN0 OiBgJFxtdSRgIGlzIGFuCml0YWxpY2l6ZWQgzrwgdG8gYmUgdXNlZCBpbiBtYXRoIGZvcm11bGFz LCB3aGVyZWFzICLOvCIgYXMgaW4gIs68bSIgaXMgYQpTSSBwcmVmaXggYW5kIHNob3VsZCBiZSBp biB1cHJpZ2h0IHN0eWxlLgoKCkNoZWVycywKUmljY2FyZG8K |
From: G. M. <mi...@us...> - 2007-02-26 15:41:56
|
On 26.02.07, gr...@us... wrote: > >trying to export a document containing a greek "mu", I faced the following > >problem. > > > >Minimal example: ``2 µm PZT`` is translated by rst2latex to ``2 µm PZT`` while > >(pdf)latex expects the µ in math-mode, as the inputenc package > >(\usepackage[latin1]{inputenc}) translates it to the math command \mu > what about using latex unicode package ? * using unicode solves the above problem But: * My source is latin1 (and my default locale and editor too). * Unicode support in docutils latex export is a bit bumpy: + It would be nice, if the `inputenc` package were called with the correct output-encoding automatically instead of requiring a user-modified stylesheet. + The "Generating LaTeX with Docutils" guide (docs/user/latex.html) seems a bit outdated: The generated LaTeX documents are in latin1 encoding per default, if unicode characters are required one must set --output-encoding=utf-8 install LaTeX unicode support and add: \usepackage{ucs} \usepackage[utf8]{inputenc} to the stylesheet. - It seems the current version of rst2latex exports to utf-8 if the input is utf-8 even without --output-encoding argument. (at least, ``2 µm PZT`` is translated to ``2 µm PZT`` here) - My pdflatex (pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)) got into a compatibility mode explaining You seem to have loaded inputencoding utf8 (LaTeX kernel UTF-8) instead of utf8x (ucs.sty UTF-8). Probably you are compiling a document written for a pre-august-2004 ucs.sty. *************************** Please use \usepackage[utf8x]{inputenc} instead of \usepackage[utf8]{inputenc}. > >Is there a way to extend the rst2latex writer to wrap greek letters into an > >``\ensuremath`` command? > i think it is, if it is necessary (e.g. latex unicode not usable ?) Although not strictly "necessary", it would be convenient and "frust-reducing" if the rst2latex exporter would wrap characters that are translated to math-commands by inputenc into ``\ensuremath`` commands. (Maybe the better solution were to convince the inputenc maintainers to provide non-failing replacements in text mode.) Thanks Guenter |
From: <gr...@us...> - 2007-02-27 08:15:32
|
On Mon, 26 Feb 2007, G. Milde wrote: > On 26.02.07, gr...@us... wrote: >>> trying to export a document containing a greek "mu", I faced the follow= ing >>> problem. >>> >>> Minimal example: ``2 =B5m PZT`` is translated by rst2latex to ``2 =B5m = PZT`` > while >>> (pdf)latex expects the =B5 in math-mode, as the inputenc package >>> (\usepackage[latin1]{inputenc}) translates it to the math command \mu > >> what about using latex unicode package ? > > * using unicode solves the above problem > > But: > > * My source is latin1 (and my default locale and editor too). > > * Unicode support in docutils latex export is a bit bumpy: > > + It would be nice, if the `inputenc` package were called with the > correct output-encoding automatically instead of requiring a > user-modified stylesheet. > + The "Generating LaTeX with Docutils" guide (docs/user/latex.html) > seems a bit outdated: > > The generated LaTeX documents are in latin1 encoding per default, > if unicode characters are required one must set > --output-encoding=3Dutf-8 install LaTeX unicode support and add: > > \usepackage{ucs} > \usepackage[utf8]{inputenc} > > to the stylesheet. > > - It seems the current version of rst2latex exports to utf-8 if the > input is utf-8 even without --output-encoding argument. > (at least, ``2 =C2=B5m PZT`` is translated to ``2 =C2=B5m PZT`` here= ) > - My pdflatex (pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)) > got into a compatibility mode explaining > > You seem to have loaded inputencoding utf8 > (LaTeX kernel UTF-8) instead of utf8x (ucs.sty UTF-8). > Probably you are compiling a document written for a > pre-august-2004 ucs.sty. > *************************** > Please use \usepackage[utf8x]{inputenc} instead of > \usepackage[utf8]{inputenc}. > >>> Is there a way to extend the rst2latex writer to wrap greek letters int= o an >>> ``\ensuremath`` command? > >> i think it is, if it is necessary (e.g. latex unicode not usable ?) > > > Although not strictly "necessary", it would be convenient and > "frust-reducing" if the rst2latex exporter would wrap characters that > are translated to math-commands by inputenc into ``\ensuremath`` > commands. i could offer 1. if outputenc is not utf8 replace some more chars (greek for example) by there latex coding. ``2 =C2=B5m PZT`` to ``2 \ensuremath{\mu}=B5m PZ= T`` 2. if outputenc is utf8, write :: \usepackage{ucs} \usepackage[utf8]{inputenc} or is it ``utf8x`` ? is it possible to force ``utf8`` then if someone desires, will stylesheets overwrite this ? anything else ? cheers --=20 |
From: <gr...@us...> - 2007-02-27 15:10:08
|
On Tue, 27 Feb 2007, G. Milde wrote: > I had a look at inputenc.sty (and an old inputenc.ps I found on the net): > The substitutions are defined in "definition files". > > * characters that are defined with DeclareInputMath use a math > command. > * characters that are defined with DeclareInputText use a text command. > > A grep of the definitions in *.def in the dir of inputenc.sty revealed the > bunch of definitions below. (where the first {nnn} arg is the dezimal char > number in the relevant encoding). the latin1 characters should be protected now. generally the writer assumes source and output coding being the same, so i might make it depend on output-encoding ? cheers -- |
From: G. M. <mi...@us...> - 2007-02-28 07:38:46
|
On 27.02.07, gr...@us... wrote: > On Tue, 27 Feb 2007, G. Milde wrote: > >I had a look at inputenc.sty (and an old inputenc.ps I found on the net): > >The substitutions are defined in "definition files". > > > >* characters that are defined with DeclareInputMath use a math > > command. > >* characters that are defined with DeclareInputText use a text command. > > > >A grep of the definitions in *.def in the dir of inputenc.sty revealed the > >bunch of definitions below. (where the first {nnn} arg is the dezimal char > >number in the relevant encoding). > the latin1 characters should be protected now. Great. > generally the writer assumes source and output coding being > the same ... however, ther option to specify a different output encoding exists, so we must not take this for granted. > , so i might make it depend on output-encoding ? Yes, as * the output-encoding is the encoding latex "sees" and expects (as it is the argument to 'inputenc' * input in a different encoding will be converted to <output-encoding> by docutils if --output-encoding=<output-encoding> is given. Thanks a lot, (looks like I have to switch from Debian package to SVN version again...) Günter |