Guenter Milde wrote:
> On 2012-03-20, Georg Baum wrote:
>
>> I do not believe a per-document solution is good. Why should a particular
>> conversion only be valid for one document?
>
> Just like other settings, the available Unicode replacements can depend
> on document settings that lyx is not aware of: I can add a
> required package, latex command and \DeclareUnicodeCharacter (if the
> document uses utf8) in the custom preamble or ERT. However, I still
> cannot use the new-defined character in LyX, as LyX is unaware of this
> replacement.
>
> One possible implementation would be a new "Unicodesymbols" section for
> LyX modules and layouts. Then, characters provided by packages or
> preamble code can be handled by modules (and local modules would allow
> the per-document configuration).
This is a very good idea. Note that this is not a what I meant with "per
document", since a module still provides only one definition of those
replacements, and the user does not need to know how to make additional
symbols available in general.
>> You can roughly divide unicode symbols in two classes: The ones like ?
>> that can be composed of glyphs existing in many fonts (in this case the
>> acute symbol on top of the small letter c), and the ones like ? that
>> require special glyphs.
I realize that my previous message was sent with the wrong encoding. The two
examples were ? (0x0107) and ? (0x2665). I hope it works this time:-)
>> The first class can be handled perfectly by the unicodesymbols file for
>> almost any font that can be used by latex/pdflatex.
>
> While the first class can be handled by the current unicodesymbols
> syntax, this is currently not allowed:
>
> # Do only add commands that give correct output, no hacks that look
> # "similar".
>
> AFIK, even using a lookalike character with different semantic is
> considered a "hack that looks 'similar'". Composing, turning, skaling or
> moving glyphs to build a new character representation has definitely more
> serious drawbacks. (This is, e.g., the reason why LyX defaults to the
> T1 font encoding instead of the LaTeX default OT1.)
It all depends. With this sentence I wanted to prevent things like the macro
for ? (0x214d), or representing ยต (0x00b5) with ? (0x03bc), but I would not
want to forbid composing like in the example above (\\'{c}).
> A "perfect" Unicode->LaTeX mapping is only given if the character in the
> output document is "recoverable", i.e. if copying from the PDF, say, will
> result in the same character as used in the input. (Actually, not all
> character mapping in "unicodesymbols" meet this criterium.)
Unfortunately not, and I have to admit that I don't agree with all of them.
OTOH, it is not always possible to have a 1:1 LyX->PDF->LyX roundtrip: E.g.
the macro I added for 0x2007 (figure space) produces output that matches
exactly the definition of this symbol, but obviously copying from PDF to LyX
will not recover it. Nevertheless, the LyX->LaTeX->LyX roundtrip works.
> We might consider offering lookalikes and substitutions on a configurable
> basis (as a module?).
Modules are the solution to everything :-)
> As txfonts, pxfonts, kmath, and kpfonts all change the look of math
> symbols as well as spacing in equations etc. (compare e.g. the math
> typesetting in the two Times-using example documents
> http://milde.users.sourceforge.net/Matheschriften/txfonts-test.pdf and
> http://milde.users.sourceforge.net/Matheschriften/tgtermes-qtxmath-
MnSymbol-test.pdf
> ), they should *never* be automatically loaded.
I see (I did not look at these packagwes too closely before). In that case,
it makes even more sense to provide a module for each of these packages that
makes the unicode replacements available.
>> For now, we could replace some of the removed characters with the pifont
>> versions (pifont is already used elsewhere in unicodesymbols). When
>> removing the txfonts symbols, I was not aware that some are also offered
>> by pifont.sty.
>
> Attention: The Unicode Character Names list states that these are
> different characters:
>
> 2764 HEAVY BLACK HEART
> x (black heart suit - 2665)
That would be \ding{164}. 0x2665 should be \ding{170} (I guess - the
linotype dingbats offering at
http://www.linotype.com/661159/ITCZapfDingbatsStd-product.html states hat
0x2665 is included, and the only matching glyph in the table in psnfss2e.pdf
is the one numbered with 170).
> Maybe the font-package descriptions (for the LyX font GUI) should provide
> a "unicodesymbols" section, too.
This is IMHO better than making the unicodesymbols syntax even more
complicated. Technically, the same mechanism could be used, though: There
could be a "private" unicodesymbols file for each font package that provides
additional symbols.
> Definitions from font-package descriptions and modules would overwrite the
> defaults in "unicodesymbols".
This works well with the original intent of this file: It should be a
fallback that is only used if everything else fails.
Georg
