Uwe Stöhr schrieb:
>> 2302 HOUSE: ⌂
>
\newcommand*\DEL{{\fontencoding{U}\fontfamily{ascii}\selectfont\char127}}
This and all other commands you sent lead to completely different
characters here on my MiKTeX-system.
Now I get it:
I have to use \usepackage{ascii} and then
{\ascii\DEL}
I s
Uwe Stöhr wrote:
>> yes, that's right, but is save to use
>>
>> \newcommand*\oline{\ensuremath{\overline{\phantom{A
>
> But then the line is a bit too long when I compare:
>
> _
> \ensuremath{\underline{\overline{\phantom{A
replace the A bei I
>
>
>>> 2302 HOUSE: ⌂
> yes, that's right, but is save to use
>
> \newcommand*\oline{\ensuremath{\overline{\phantom{A
But then the line is a bit too long when I compare:
_
\ensuremath{\underline{\overline{\phantom{A
>> 2302 HOUSE: ⌂
> \newcommand*\DEL{{\fontencoding{U}\fontfamily{ascii}
Juergen Spitzmueller wrote:
> Herbert Voss wrote:
>
>> \newcommand*\DEL{{\fontencoding{U}\fontfamily{ascii}\selectfont\char127}}
>
> perhaps \providecommand (in case the ascii package is already loaded).
but only in this case, the other way round works ... :-)
Herbert
Herbert Voss wrote:
> \newcommand*\DEL{{\fontencoding{U}\fontfamily{ascii}\selectfont\char127}}
perhaps \providecommand (in case the ascii package is already loaded).
Jürgen
Uwe Stöhr wrote:
>> \newcommand*\LyXrightangle{{\usefont{U}{msa}{m}{n}\char120}}
>
> Many thanks.
> Where is a table to look what number corresponds to what character in
> the font files? I seared for a code chart table for msam and msbm but
> couldn't found this character there.
>
> Now only the
Andre Poenitz schrieb:
(Using \={} is too short for the OVERLINE, it has to be the same length as
\_ )
\raisebox{1.3ex}{\_}
This is too low, the overline has to be in the same height as the bar above an
"M": \=M
I found out that this would then be
\raisebox{2.61ex}{\_}
Herbert, is this cor
Uwe Stöhr wrote:
> Andre Poenitz schrieb:
>
>>> (Using \={} is too short for the OVERLINE, it has to be the same
>>> length as \_ )
>>
>> \raisebox{1.3ex}{\_}
>
> This is too low, the overline has to be in the same height as the bar
> above an "M": \=M
> I found out that this would then be
> \rai
On Wed, May 30, 2007 at 02:24:15AM +0200, Uwe Stöhr wrote:
> > \newcommand*\LyXrightangle{{\usefont{U}{msa}{m}{n}\char120}}
>
> Many thanks.
> Where is a table to look what number corresponds to what character in the
> font files? I seared for a code chart table for msam and msbm but couldn't
>
On Wed, May 30, 2007 at 02:24:15AM +0200, Uwe Stöhr wrote:
> > \newcommand*\LyXrightangle{{\usefont{U}{msa}{m}{n}\char120}}
>
> Many thanks.
> Where is a table to look what number corresponds to what character in the
> font files? I seared for a
> code chart table for msam and msbm but couldn't
> \newcommand*\LyXrightangle{{\usefont{U}{msa}{m}{n}\char120}}
Many thanks.
Where is a table to look what number corresponds to what character in the font files? I seared for a
code chart table for msam and msbm but couldn't found this character there.
Now only these characters used in Windows
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 c
Enrico Forestieri wrote:
> Maybe something like {\usefont{OT1}{cmr}{m}{n}\charXX} ?
> See attached latex file.
But this is hardcoded to computer modern.
An alternative would be to load greek babel and use the \textgreek{} macro
(that only switches the encoding, not the language AFAIK).
There's a
Uwe Stöhr wrote:
>>>"\\newcommand{\\lyxcareof}{\\leavevmode\\hbox{\\raise.75ex\\hbox{c}\\kern-.15em/\\kern-.125em\\smash{\\lower.3ex\\hbox{o}}}\\ignorespaces}"
>
>>> ""
>>
>> \newcommand*\lyxcareof{%
>> \mbox{\raisebox{.8ex}{c}\kern-.175em\raisebox{.2ex}{/}%
>> \kern-.18em\raisebox{-.2ex}{o}}}
>
On Monday 28 May 2007 18:16:32 Jean-Marc Lasgouttes wrote:
> Agreed.
+1
> JMarc
--
José Abílio
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Am Montag, 28. Mai 2007 10:58 schrieb Abdelrazak Younes:
>> OK, then shouldn't we switch altogether to the unicodesymbols file
>> and forget about this inputenc package? Or maybe this is too much
>> work?
Georg> That would blow up the
On Mon, May 28, 2007 at 11:00:24AM +0200, Georg Baum wrote:
> Am Montag, 28. Mai 2007 10:48 schrieb Jürgen Spitzmüller:
> > Georg Baum wrote:
> > > Note that adding the symbols in question to the unicodesymbols file
> will
> > > automatically solve the problem of broken latex export for greek
>
On Mon, 28 May 2007, Uwe Stöhr wrote:
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,
>>"\\newcommand{\\lyxcareof}{\\leavevmode\\hbox{\\raise.75ex\\hbox{c}\\kern-.15em/\\kern-.125em\\smash{\\lower.3ex\\hbox{o}}}\\ignorespaces}"
>> ""
>
> \newcommand*\lyxcareof{%
> \mbox{\raisebox{.8ex}{c}\kern-.175em\raisebox{.2ex}{/}%
> \kern-.18em\raisebox{-.2ex}{o}}}
Thanks I use now your sol
Uwe Stöhr <[EMAIL PROTECTED]> writes:
| >> Note that adding the symbols in question to the unicodesymbols file will
| >> automatically solve the problem of broken latex export for greek
| >> characters that are not marked at greek, without any hack needed.
| >
| > That would be great. But how
>> Note that adding the symbols in question to the unicodesymbols file will
>> automatically solve the problem of broken latex export for greek
>> characters that are not marked at greek, without any hack needed.
>
> That would be great. But how should the entries look like?
I don't like this. I
Uwe Stöhr wrote:
>> But I would do it like this:
>>
>> 0x2105 "\\lyxcareof" "" "\\newcommand{\\lyxcareof}
>>
> {\\leavevmode\\hbox{\\raise.75ex\\hbox{c}\\kern-.15em/\\kern-.125em\\smash{\\lower.3ex\\hbox{o}}}\\ignorespaces}"
>
>>
>> # CARE OF
>
> This doesn't work but this:
>
> # following macr
>> 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
>
Am Montag, 28. Mai 2007 10:58 schrieb Abdelrazak Younes:
> OK, then shouldn't we switch altogether to the unicodesymbols file and
> forget about this inputenc package? Or maybe this is too much work?
That would blow up the file size and generate complaints from people who
want to exchange their
Am Montag, 28. Mai 2007 10:48 schrieb Jürgen Spitzmüller:
> Georg Baum wrote:
> > Note that adding the symbols in question to the unicodesymbols file
will
> > automatically solve the problem of broken latex export for greek
> > characters that are not marked at greek, without any hack needed.
>
>
Georg Baum wrote:
Am Montag, 28. Mai 2007 10:31 schrieb Abdelrazak Younes:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I would say in the LateX export but Georg wouldn't agree with me I
think.
I would agree. It would ease to implement a special symbols panel later
(that
uses unicode
Am Montag, 28. Mai 2007 10:31 schrieb Abdelrazak Younes:
> Jürgen Spitzmüller wrote:
> > Abdelrazak Younes wrote:
> >> I would say in the LateX export but Georg wouldn't agree with me I
think.
> >
> > I would agree. It would ease to implement a special symbols panel later
(that
> > uses unicode
Georg Baum wrote:
> Note that adding the symbols in question to the unicodesymbols file will
> automatically solve the problem of broken latex export for greek
> characters that are not marked at greek, without any hack needed.
That would be great. But how should the entries look like?
Jürgen
Am Montag, 28. Mai 2007 10:13 schrieb Abdelrazak Younes:
> Jürgen Spitzmüller wrote:
> > But since we are on the topic: Georg, how should this specific case be
> > implemented? I thought about something like
> >
> > bool Encodings::is_greek(char_type c)
> > {
> > return 0x0370 <= c <= 0x03ff
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I would say in the LateX export but Georg wouldn't agree with me I think.
I would agree. It would ease to implement a special symbols panel later (that
uses unicode-insert).
That is a good use-case indeed. Setting the language to properly t
Abdelrazak Younes wrote:
> I would say in the LateX export but Georg wouldn't agree with me I think.
I would agree. It would ease to implement a special symbols panel later (that
uses unicode-insert).
Jürgen
Jürgen Spitzmüller wrote:
Georg Baum wrote:
I don't know why everybody states this when I never wrote to do this.
I simply used the misunderstanding of Jürgen as a cause to mention that
adding them 'correctly' would indeed make sense.
Same for me. I didn't mean to point my arguments towards U
Georg Baum wrote:
> > I don't know why everybody states this when I never wrote to do this.
>
> I simply used the misunderstanding of Jürgen as a cause to mention that
> adding them 'correctly' would indeed make sense.
Same for me. I didn't mean to point my arguments towards Uwe in any way, but
w
Am Sonntag, 27. Mai 2007 20:49 schrieb Uwe Stöhr:
> > I agree with Jürgen that the ordinary greek characters 0x0370..0x03ff
> > should not be added as math versions.
>
> I don't know why everybody states this when I never wrote to do this.
I simply used the misunderstanding of Jürgen as a caus
Uwe Stöhr wrote:
> > Probably \DEL (package ascii).
>
> No, this produces a character similar to "_" for me here.
Then your installation is probably wrong. Look here:
ftp://tug.ctan.org/pub/tex-archive/info/symbols/comprehensive/symbols-a4.pdf
(page 49)
Jürgen
Attached is the patch including Georg's advices. Can this go in?
+1 for RC1 testing.
Cheers,
Bo
>> - the math characters used by Windows also for text that are not
>> supported by textcomp are implemented as math characters using
>> \ensuremath. Instead of \ensuremath{..} I can also use $..$, what is
>> better?
>
> \ensuremath.
OK.
> I agree with Jürgen that the ordinary greek characters 0
>> c/o,
>
> I'm not aware of an approach to directly access the symbol, but this is the
> most frequent macro (used in tugboat):
>
> \def\careof{\leavevmode\hbox{\raise.75ex\hbox{c}\kern-.15em
> /\kern-.125em\smash{\lower.3ex\hbox{o}}} \ignorespaces}
Thanks, this looks good but I
Am Sonntag, 27. Mai 2007 02:06 schrieb Uwe Stöhr:
> The attached patch implements all, except of 5, characters reported by
the
> users in bug 3673.
>
> - the math characters used by Windows also for text that are not
> supported by textcomp are implemented as math characters using
> \ensuremath.
Uwe Stöhr wrote:
> With this patch only these 5 characters remain:
> c/o,
I'm not aware of an approach to directly access the symbol, but this is the
most frequent macro (used in tugboat):
\def\careof{\leavevmode\hbox{\raise.75ex\hbox{c}\kern-.15em
/\kern-.125em\smash{\lower.3
The attached patch implements all, except of 5, characters reported by the
users in bug 3673.
- the math characters used by Windows also for text that are not
supported by textcomp are implemented as math characters using
\ensuremath. Instead of \ensuremath{..} I can also use $..$, what is
better
The attached patch implements all characters reported by the users in bug 3673.
- the math characters used by Windows also for text that are not supported by textcomp are
implemented as math characters using \ensuremath. Instead of \ensuremath{..} I can also use $..$,
what is better?
- the fr
42 matches
Mail list logo
