Uwe Stöhr wrote:
> >> What about the c/o problematic I reported in my last email?
> >
> > You mean the automatic translation to c, / and o?
>
> Yes.
>
> > That is probably done by
> > word. iconv is not used here (at least not directly, maybe internally
> > by qt, but if it would do this change whan asked to convert from utf16
> > (QString) to ucs4 (docstring) it would be a bug). Paste from word to a
> > real text editor, and/or add some debug output in GuiClipboard if you
> > want to find it out.
>
> Word is definetively not guilty here. I can copy the ℅ character to and
> from any program on my computer, only copying to LyX destroys the single
> character to three.
Then add the debug output in GuiClipboard to have a look what comes from qt.
If that is already 3 characters then this is probably a qt bug
('feature'?).
> The strange thing is: When I add this character to a
> LyX file using a text editor and then opening the LyX-file with LyX, the
> character is corretly shown and I can then also copy it inside LyX and
> from LyX to other applications. So only the copying to LyX fails.
This is not strange. LyX can process all characters from the UCS4 range
internally. It might not be able do draw them correctly if no suitable font
is available, and LaTeX export may fail, but everything else is supposed to
work. Strange is that you see this split up, this is not supposed to
happen.
> I noticed that the command must be in one line.
Yes, this simplifies the parsing of the unicodesymbols file. If you have
more complicated macros you can always put them in LaTeXFeatures.
Georg
PS: Your latest patch for the unicodesymbols file has some misordered
symbols (around 0x212a). I also hope that you did not enter all these
symbols by hand, but are aware that there is a script
development/tools/unicodesymbols.py that adds them including the official
names (see the head of unicodesymbols for details), so that you only need
to fill in the LaTeX stuff.
