Simply include the attached file somewhere at the beginning of a
document to have Cyrillic support (however, due to the used
extension mechanism, you don't get kerning or hyphenation, even if
you set the document language to Russian).
I've committed a slightly improved version to the git
Werner LEMBERG w...@gnu.org writes:
Simply include the attached file somewhere at the beginning of a
document to have Cyrillic support (however, due to the used
extension mechanism, you don't get kerning or hyphenation, even if
you set the document language to Russian).
I've committed a
I don't see this hack as the canonical way to go forward,
Interesting. I'm all ears to any more sensible solution which extends
the texinfo.tex framework without completely rewriting the font
selection mechanism.
and it is certainly not of the obviously trivial and correct
quality
Werner LEMBERG w...@gnu.org writes:
I don't see this hack as the canonical way to go forward,
Interesting. I'm all ears to any more sensible solution which extends
the texinfo.tex framework without completely rewriting the font
selection mechanism.
and it is certainly not of the obviously
I don't have more than the power of appeal to ask people from
refraining sabotaging the development branch until the settling
phase of 2.16 is mostly over, and that will be the case when 2.16.0
and 2.17.0 have been released: everything that actually should be
in 2.16.0 but did not warrant
Werner LEMBERG w...@gnu.org writes:
I don't have more than the power of appeal to ask people from
refraining sabotaging the development branch until the settling
phase of 2.16 is mostly over, and that will be the case when 2.16.0
and 2.17.0 have been released: everything that actually should
On Mon, Aug 13, 2012 at 08:16:48PM +0200, David Kastrup wrote:
Werner LEMBERG w...@gnu.org writes:
Hmm, `wild changes' is a mild exaggeration, isn't it? It makes
50 Cyrillic characters appear in the PDFs which were simply missing
previously. It's a one-line change in `macros.itexi'
and
In macros.itexi which is used throughout the entire documentation, for
every single Texinfo document, whether generating PDF, info, HTML. Have
you checked the performance impact?
Performance impact? For building the documentation? Are you kidding?
Building the snippets with LilyPond takes
But as soon as somebody complained (regardless of who it was,
regardless of the reason), I would revert the commit, and send the
patch for review+countdown.
Just done.
In the future, we'll all remember that changes to texinfo.tex can be
problematic, so we'll be slightly less likely to take
Graham Percival gra...@percival-music.ca writes:
On Mon, Aug 13, 2012 at 08:16:48PM +0200, David Kastrup wrote:
Werner LEMBERG w...@gnu.org writes:
Hmm, `wild changes' is a mild exaggeration, isn't it? It makes
50 Cyrillic characters appear in the PDFs which were simply missing
Pushing to staging means I consider this change to be safe and
can't imagine anybody suggesting anything to change.
Actually, this is what I still believe. However, we probably agree to
disagree, and going the Rietveld route is certainly the safe way.
For changes with potentially large
On Mon, Aug 13, 2012 at 09:16:24PM +0200, David Kastrup wrote:
Graham Percival gra...@percival-music.ca writes:
Yes. Pushing directly to staging is basically a gamble:
IF YOU WIN: you avoid the delay and hassle of git-cl, reviews, a
patch countdown, etc.
IF YOU LOSE: somebody doesn't
12 matches
Mail list logo
