sorry -- typo -- I meant the setup (thanks to Ulrike) of \zhtone{\u}{ü}.<br><br>as ever,<br>Rembrandt<br><br><div class="gmail_quote">On Fri, May 8, 2009 at 07:21, Rembrandt Wolpert <span dir="ltr"><<a href="mailto:wolpert@uark.edu">wolpert@uark.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">However, as pointed out before, there are instances where there isn't a glyph in a (publisher-required) font, and one has to compose one with the \u\ü combination, for example. So I am happy that there is a possibility to compose a needed combination. After all, it's not the input I want to be read, but the output...<br>
<br>as ever,<br>Rembrandt<div><div></div><div class="h5"><br><br><br><div class="gmail_quote">On Fri, May 8, 2009 at 06:54, Benct Philip Jonsson <span dir="ltr"><<a href="mailto:bpj@melroch.se" target="_blank">bpj@melroch.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On 2009-05-07 Ulrike Fischer wrote:<br>
</div><div>> I would certainly never use \"u instead of ü. But I at<br>
> least do find it much easier to use commands for symbols<br>
> I use rather seldom than to set up a lot of shortcuts in<br>
> my editor which I will probably not remember when I need<br>
> them.<br>
<br>
</div>That's true, but there again I use XIM, so,<br>
I'll rather type <Compose><!><d>.<br>
<br>
I guess the real difference between us is that I feel<br>
those \<CHAR>{<ARG>} commands make for utter unreadability,<br>
and my main reason for using XeLaTeX is exactly that I<br>
won't have to use them.<br>
<div><br>
> And even with pdflatex I don't use all chars I<br>
> could input directly. E.g. I always use -- and --- and<br>
> not the corresponding unicode glyphs because at my<br>
> opinion it is much more readable.<br>
<br>
</div>I'm all with you on that one!<br>
<div><br>
> Also using the direct glyph will not solve the problem<br>
> discussed here. If a glyph is not in a font it doesn't<br>
> reappear if you use another input method.<br>
><br>
> And at last: commands can be defined to work in various<br>
> circumstances. \d{<ARG>} will work with new open type<br>
> fonts *and* with old OT1/T1 encoded fonts and with a lot<br>
> of <ARG>'s -- and you can easily redefine it. It is quite<br>
> possible that a future xunicode defines \d in such a way<br>
> that it tests if the glyph is in the font and use a<br>
> fallback if not.<br>
<br>
</div>I would rather have the software be smart enough to check<br>
for each Unicode character in my input file if it exists<br>
in the font, failing that to try replacing it with the<br>
corresponding Normalization Form Canonical Decomposition and<br>
failing that<br>
to try some other fallback. That kindh of checking and<br>
rote memorization is what computers are supposed to be<br>
good at and we shouldn't have to use a markup command to<br>
triger that checking; it should be done automatically<br>
for every multi-byte character. Is it too much in this day<br>
and age to expect the software to be aware of Unicode<br>
equivalence and do someting smart with it? If xunicode<br>
already is smart enough to have "\d{d}" trigger a check<br>
if \char"1E0D exists in the output font why can't "ḍ" on its<br>
own trigger such a check?<br>
<div><div></div><div>_______________________________________________<br>
XeTeX mailing list<br>
<a href="mailto:postmaster@tug.org" target="_blank">postmaster@tug.org</a><br>
<a href="http://tug.org/mailman/listinfo/xetex" target="_blank">http://tug.org/mailman/listinfo/xetex</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><font color="#888888">-- <br> 人有不為也而後可有為<br>
</font></blockquote></div><br><br clear="all"><br>-- <br> 人有不為也而後可有為<br>