On Tue, Jul 24, 2012 at 04:45:51AM +0200, Werner LEMBERG wrote:
There are *zero* chances that CJK support
(probably based on my package) will ever be added to texinfo for the
original tex or pdftex engine.
I suspected this might be the case.
With XeTeX and luatex, native CJK support
An even better solution would be for Texinfo to support these
characters.
- Just saying - I wouldn't expect any Lily developers to be working
on that!
Well, some years ago I've added UTF-8 infrastructure support to
texinfo (based on the LaTeX code); additionally, I've written the CJK
On Mon, Jul 23, 2012 at 03:26:22AM +0200, Werner LEMBERG wrote:
An even better solution would be to
provide a big square with four small digits in it, giving the
character's Unicode value.
An even better solution would be for Texinfo to support these characters.
- Just saying - I wouldn't
Try the dev/texinfo branch. It is not really suitable for Rietveld
since it is two commits: one the current Texinfo version, and the
second a much smaller commit just changing the problematic lines.
Two days ago I've built the documentation, and everything seems fine.
Thanks a lot!
One
Werner LEMBERG w...@gnu.org writes:
Hmm, that brings to mind a different possible solution:
@macro lilyfile{\FILENAME\}
@/@file{\FILENAME\}
@end macro
if there's no way to automate our desired behaviour (assuming we
can agree on a desired formatting in the output!), this might be
an
this-is-a-very
-long-name.ly
No, I don't like that idea. Filenames shouldn't be hyphenated.
I disagree. By starting a line with the hyphen it is clear that it is
part of the file name and not due to hyphenation (and we use a
typewriter font also). It is *much* less ugly than overlong
It is very unfortunate that we can't upgrade to the current
texinfo.tex file; it contains a lot of improvements, including a
very flexible URL command.
Why can't we? If it is ok for us to distribute a modified version
of texinfo.tex, I am pretty sure that I can concoct a fix for
whatever
Werner LEMBERG w...@gnu.org writes:
It is very unfortunate that we can't upgrade to the current
texinfo.tex file; it contains a lot of improvements, including a
very flexible URL command.
Why can't we? If it is ok for us to distribute a modified version
of texinfo.tex, I am pretty sure
On Thu, Jul 12, 2012 at 02:07:39AM +0200, Werner LEMBERG wrote:
It is very unfortunate that we can't upgrade to the current
texinfo.tex file; it contains a lot of improvements, including a very
flexible URL command.
Why can't we do this? Do we just have to many custom hacks in our
existing
LGTM
Trevor
http://codereview.appspot.com/6345088/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. Thanks a lot!
http://codereview.appspot.com/6345088/diff/1/Documentation/snippets/simultaneous-headword.ly
File Documentation/snippets/simultaneous-headword.ly (right):
http://codereview.appspot.com/6345088/diff/1/Documentation/snippets/simultaneous-headword.ly#newcode16
black bars in NR (issue 6345088)
LGTM. Thanks a lot!
http://codereview.appspot.com/6345088/diff/1/Documentation/snippets/simultaneous-headword.ly
File Documentation/snippets/simultaneous-headword.ly (right):
http://codereview.appspot.com/6345088/diff/1/Documentation/snippets/simultaneous
I've only looked at the first few files, but I have grave concerns with
this patch.
I feel terrible about it, though. Please, PLEASE, anybody who wants to
make lots of changes to the docs -- spend *at most* one hour working on
your changes, then submit them to get feedback. It must have taken
Subject: Re: Fixes all black bars in NR (issue 6345088)
I've only looked at the first few files, but I have grave concerns with
this patch.
I feel terrible about it, though. Please, PLEASE, anybody who wants to
make lots of changes to the docs -- spend *at most* one hour working on
your changes
Phil Holmes em...@philholmes.net writes:
@*
@file{blah}
David doesn't like @* so I avoided it. I'll use @*
@* is awful. It cuts the current line _short_ unconditionally which
means that we may get abysmally bad breaks when the paragraph content
changes. It makes more sense to use @/ which
On Wed, Jul 11, 2012 at 10:32:28PM +0200, David Kastrup wrote:
Phil Holmes em...@philholmes.net writes:
David doesn't like @* so I avoided it. I'll use @*
@* is awful. It cuts the current line _short_ unconditionally which
means that we may get abysmally bad breaks when the paragraph
Graham Percival gra...@percival-music.ca writes:
On Wed, Jul 11, 2012 at 10:32:28PM +0200, David Kastrup wrote:
Phil Holmes em...@philholmes.net writes:
David doesn't like @* so I avoided it. I'll use @*
@* is awful. It cuts the current line _short_ unconditionally which
means that we
Hmm, that brings to mind a different possible solution:
@macro lilyfile{\FILENAME\}
@/@file{\FILENAME\}
@end macro
if there's no way to automate our desired behaviour (assuming we
can agree on a desired formatting in the output!), this might be
an alternate solution?
It is very
18 matches
Mail list logo
