From: Kirill S. <ki...@mn...> - 2010-03-31 08:12:17
|
On Tue, Mar 30, 2010 at 07:51:24AM +0000, Guenter Milde wrote: > On 2010-03-29, Kirill Smelkov wrote: > > On Sun, Mar 07, 2010 at 09:51:03PM +0000, Guenter Milde wrote: > >> On 2010-03-05, Kirill Smelkov wrote: > >> > On Fri, Mar 05, 2010 at 08:39:58AM +0000, Guenter Milde wrote: > >> >> On 2010-03-04, Kirill Smelkov wrote: > >> >> > On 2010-03-04 02:00 Guenter Milde wrote: > > >> ... > > >> >> It looks like XeTeX would be a clean option here. > > > Yes, XeTeX makes sense. > > > I use Debian/testing at home, but at work we are bound to Debian/stable, > > so unfortunately will have a chance to use TeXLive2009 only when squeeze > > goes into freeze. > > > Also, we do combined Docutils/TeX approach, and there is some math, so I > > guess right now I'd better stick to pdfTeX, but will have an eye on > > XeTeX occasionally. > > The XeTeX from TeXLive 2007 in Debian/stable should work as well. You > will not have unicode-math, i.e. equations will be set with TeX fonts > (usually Computer Modern). However, you would be free to use type1 > (scalable vector) system fonts for Greek (insted of the math-greek hack) > and Cyrillic (I am missing good Cyrillic type 1 TeX fonts on my Debian > system.) Thanks for the info. Still a bit reluctant to go the XeTeX route. To me TeX/pdfTeX have their warts, but they are proven enough to justify their use, and while XeTeX seems great, I don't want to invest time into preliminary technologies (maybe I'm wrong, yes), but for example babel not working with XeTeX is an alarm for me. As to fonts, I'm not an expert in the topic, and even not a good-understanding user, so I can't tell wheter my fonts are good or bad. I use cyrtimes and friends from scalable-cyrfonts-tex, and though hardcopy looks good (to me at least), displaying on screen is indeed are harder to read in kpdf, but better in xpdf. I suspect I'm telling something silly above - will investigate this topic in low priority mode... > > And I look forward for XeTeX support in Docutils. > > Please be patient, I don't know how much effort this will take, so > there is no "release date" yet. > > ... Sure, noone is in hurry. > > Thanks for all the options. Here is what I ended up doing in custom > > package which always gets included first by custom class: > > If the class is always used with this settings, you could consider > putting them direcly in the documentclass definition file. > ... This is the way I do it -- all my classes (I have several of them), always include this generic stuff first. > > So the key here is > > > \RequirePackage[utf8,utf8x]{inputenc} > > > which says ucs to be used in compatibility mode which does not (to my > > knowledge) interfere with standard utf8 inputenc and only extend it. And > > also this does not conflict with later > > > \usepackage[utf8]{inputenc} % note no utf8x > > > generated by Docutils. > > Still it looks like a hack. Yes, it's a hack, but it works, and it's a less headache for everyone. > This is why I prepared a patch to drop the > ``\usepackage[<encoding>]{inputenc}`` call if the latex source encoding > is 'ascii'. > This way you can specify \usepackage[utf8]{inputenc}, either in a custom > document class or in a custom template (see the latex writer > documentation on templates). Yes, I know about templates. As to 'ascii' -- doesn't it look like haskish solution too? Or at least non obvious - because you are going to tell users "set latex source encoding to ascii throug .conf or command line" (btw how, output_encoding=ascii ?) , and then latex2e would omit generating \usepackage[utf8]{inputenc}, and then you can you use own custom template where you specify [utf8]{inputenc}. This sounds like too much magic instead of plain option telling latex2e to omit generating {inputenc} preamble. Or better - why at all we mix inputenc into $requirements? To me low level stuff like fontenc, and inputenc would be better split into separate say $encspec, and then it would be possible for demanding users, to override such setting in ther default.tex file. Just my 2c - I've already settled on this with my utf8x compatibility mode hack. > > So yes, let's drop my utf8x patches completely -- it's only an > > intermediate solution until xetex / luatex emerge, and in the meantime > > those who want it (i.e. me) could always do it with custom class. > > Could you close the tracker items or does this need developer access? I've closed two related tracker items just after sending my "head ups". http://sourceforge.net/tracker/index.php?func=detail&aid=2962768&group_id=38414&atid=422032 http://sourceforge.net/tracker/index.php?func=detail&aid=2962763&group_id=38414&atid=422032 am I missing something? Thanks, Kirill |