On 2012-03-20, Georg Baum wrote:
> Vincent van Ravesteijn wrote:
>>>>>> I don't know what is supposed to happen to these characters.
> Basically nothing (see below).
>>> Like the other ca. 1000 out of 2751 Unicode math-related symbols without
>>> (traditional) LaTeX support, they cannot be auto-converted to a LaTeX
>>> command by LyX.
>>> * File a bug/enhancement report for "conditional" conversions in
>>> "unicodesymbols", i.e. conversions that are active if LyX detects that
>>> the required command is available in the document without auto-loading
>>> packages.
>>> * File a bug/enhancement report asking for a way to add Unicode->LaTeX
>>> conversions on a per-document basis.
> 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).
----------
> 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.
> 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.)
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.)
We might consider offering lookalikes and substitutions on a configurable
basis (as a module?).
> The second class cannot be handled in a generic way, since it either
> requires a font with an extended set of glyphs, or an additional font
> that provides the extra glyphs. In the latter case the additional font
> is almost always tied to a particular main font (otherwise the output
> would not look good, although many people don't care). What is needed
> here is a more flexible mechanism for mapping these symbols to LaTeX
> commands: Depending on the main document font chosen, LyX should use
> different LaTeX commands provided by different packages.
While in this case the output can be "perfect", the syntax of LyX's
unicodesymbols file needs additions to handle the conditional mappings.
> E.g. if the main document font is times, it could output ? with
> $\varheartsuit$ using txfonts.sty, with $\varheartsuit$ using pxfonts.sty if
> the main font is palatino, or else with \ding{170} using pifont.sty.
> You cannot always use pifont, since it looks bad for some fonts, e.g. times
> (compare $\heartsuit$ with \ding{170}).
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.
> 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)
> Unfortunately I don't know how such a solution could look like in practice.
Mappings provided by a module are one possibility, suited for
glyph-providing packages that are typically added by the user (in LaTeX
via \usepackage) and have few side-effects.
Another possibility, suited, e.g., for fonts selected by LyX's font
selection GUI, is an extension to the syntax of unicodesymbols, adding
conditionals and alternatives, e.g.
0x2665 "" "" "" "\\varheartsuit" "txfonts?|pxfonts?|kmath?|kpfonts?"
to define \varheartsuit only if one of the four listed features (packages) is
already available.
This does not yet solve the case of different commands for the same
character by different packages, e.g.
0x2665 "" "" "" "\\varheart" "arevmath?"
Maybe the font-package descriptions (for the LyX font GUI) should provide
a "unicodesymbols" section, too.
Definitions from font-package descriptions and modules would overwrite the
defaults in "unicodesymbols".
Günter
