Re: Fixes all black bars in NR (issue 6345088)
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 (looking at the character > set) is trivial. However, neither engine is supported by texinfo > natively, but this may change. > Personally I would like to see CJK support as widely available as possible - I was married to a Chinese lady for over 25 years. > It should be not too difficult to add some macros for proper Greek and > Cyrillic (within the lilypond framework), and I will have a look if > time permits. > That looks interesting! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
> 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 package for LaTeX to support various east Asian scripts, so I think I have some competence here. 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. It took more than 10 years that the texinfo team changed from Knuth's CM fonts to the EC fonts so that a broader range of European scripts are available. Main reason for such a conservative behaviour is backwards compatibility. With XeTeX and luatex, native CJK support (looking at the character set) is trivial. However, neither engine is supported by texinfo natively, but this may change. It should be not too difficult to add some macros for proper Greek and Cyrillic (within the lilypond framework), and I will have a look if time permits. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
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 expect any Lily developers to be working on that! Bernard ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
> 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 issue to resolve yet is how we handle unavailable Unicode characters. While inclusion of PDF snippets now work, texinfo itself only supports a small set of characters. If you do `grep @u8 *.log', you get 218 lines like these contributor.log:l.704: Unicode char @u8:⋮ not defined for Texinfo music-glossary.log:l.3571: Unicode char @u8:σ not defined for Texinfo notation.log:l.3406: Unicode char @u8:д not defined for Texinfo snippets.log:l.1903: Unicode char @u8:ק not defined for Texinfo web.log:l.2068: Unicode char @u8:語 not defined for Texinfo without any indication in the output files that glyphs are missing. A quick solution could be to redefine texinfo.tex's internal `\UTFviiiDefined' command to not only emit a warning but print a `not available' glyph like `X'. An even better solution would be to provide a big square with four small digits in it, giving the character's Unicode value. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
Werner LEMBERG 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 that I can concoct a fix for >> whatever the problem is. > > I meant: We can't upgrade without hacking it. The `\' vs. `\\' issue > in @lydoctitle is an incompatibility (I've CCed you in May). If you > like to fix that for lilypond's usage, please do so! 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. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
>> 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 the problem is. I meant: We can't upgrade without hacking it. The `\' vs. `\\' issue in @lydoctitle is an incompatibility (I've CCed you in May). If you like to fix that for lilypond's usage, please do so! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
>> 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 or too short lines. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
Werner LEMBERG 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 alternate solution?
>
> 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 the
problem is.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
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 texinfo.tex ? > What should be possible is to directly hack texinfo.tex so that file > names are broken either after or before a hyphen. I prefer the > latter, BTW: > > this-is-a-very > -long-name.ly No, I don't like that idea. Filenames shouldn't be hyphenated. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
> 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 unfortunate that we can't upgrade to the current
texinfo.tex file; it contains a lot of improvements, including a very
flexible URL command.
What should be possible is to directly hack texinfo.tex so that file
names are broken either after or before a hyphen. I prefer the
latter, BTW:
this-is-a-very
-long-name.ly
This makes it clear that the hyphen is not accidentally present due to
a line break.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
Graham Percival writes:
> On Wed, Jul 11, 2012 at 10:32:28PM +0200, David Kastrup wrote:
>> "Phil Holmes" 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 content
>> changes. It makes more sense to use @/ which merely permits linebreaks.
>
> 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?
Pointless. There is already in general a space before @file which is a
permissible line break. If you want to break inside of file names, you
need to manually sprinkle the file name itself with @/.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
On Wed, Jul 11, 2012 at 10:32:28PM +0200, David Kastrup wrote:
> "Phil Holmes" 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 content
> changes. It makes more sense to use @/ which merely permits linebreaks.
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?
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
"Phil Holmes" 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 merely permits linebreaks.
>> http://codereview.appspot.com/6345088/diff/1/Documentation/notation/fretted-strings.itely#newcode1404
>> Documentation/notation/fretted-strings.itely:1404:
>> @file{ly/predefined-guitar-fretboards.ly}, @*
>> oh god. Seriously?! there _has_ to be a better way to make tex behave.
>>
>> hmm, maybe these could be wrapped in an @example? it's icky, though.
>> Not a serious suggestion.
>
> To be honest, it didn't seem worth worrying about too much. It's
> basically a list of filenames. Separating them with line break isn't
> a big deal, and at least allows the user to read them?
Makes for inconsistent formatting of lines. Making an example block or
a one-column "table" seems to make for more consistent results.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
- Original Message -
From:
To: ; ;
; ;
Cc: ;
Sent: Wednesday, July 11, 2012 8:45 PM
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, then submit them to get feedback. It must have taken a
long time to do all this, and if it doesn't get accepted this will be a
real shame.
(some parts of this patch are obviously good and could be pushed
directly, but they're all mixed in with parts that I have concerns
about, so it's problematic)
Probably about 4 or 5 hours, so it's not desperate. The problem with stuff
like this is that there's no real point in doing a little bit - you either
fix the lot or none. Don't worry about adverse comments - I'm happy to
receive them providing we remember the aim is to make things better -
occasionally we stray into keeping the _very_ poor status quo instead of
implementing a _slightly_ poor change.
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/fretted-strings.itely#newcode1134
Documentation/notation/fretted-strings.itely:1134: The file
@file{predefined-ukulele-fretboards.ly} contains the fret
I'm not a fan of this change. I'd rather have a manual line-break on
its own line:
... are contained in the file
@*
@file{blah}
David doesn't like @* so I avoided it. I'll use @*
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/fretted-strings.itely#newcode1404
Documentation/notation/fretted-strings.itely:1404:
@file{ly/predefined-guitar-fretboards.ly}, @*
oh god. Seriously?! there _has_ to be a better way to make tex behave.
hmm, maybe these could be wrapped in an @example? it's icky, though.
Not a serious suggestion.
To be honest, it didn't seem worth worrying about too much. It's basically
a list of filenames. Separating them with line break isn't a big deal, and
at least allows the user to read them?
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/input.itely#newcode1359
Documentation/notation/input.itely:1359:
@lilypond[verbatim,papersize=a8landscape]
why is this necessary? Does lilypond-book not select the appropriate
paper size when there's a \book{} inside the example? If that's the
case, it should be solved with lilypond-book, not by manually changing
every @lilypond that involves \book.
(this sounds slightly familiar. Didn't we have a round of bugfixes in
lilypond-book on this problem?)
Kind of, but not this one specifically. Look at the old version - it's
crap. This makes it work for an odd example that depends on multiple page
examples, which are rare. Also check the CG -
http://lilypond.org/doc/v2.15/Documentation/contributor/lilypond-formatting
- a8landscape is specifically recommended.
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/notation-appendices.itely#newcode48
Documentation/notation/notation-appendices.itely:48: @c The line width
is a hack to allow space for instrument names
I really don't like seeing hacks like this in the docs; it's just
wall-papering over flaws in lilypond itself. There should be a way to
tell lilypond "you have this much width on the page", and then lilypond
should select an appropriate line-width for the first line of the score
in order to have enough space for the instrument names.
http://codereview.appspot.com/6345088/
Kind-of agreed. But if there's a flaw in lilypond, we shouldn't make that
flaw a defining feature by emphasising it in the docs. My suggestion is
that you should either fix the flaw or accept the change
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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, then submit them to get feedback. It must have taken a
long time to do all this, and if it doesn't get accepted this will be a
real shame.
(some parts of this patch are obviously good and could be pushed
directly, but they're all mixed in with parts that I have concerns
about, so it's problematic)
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/fretted-strings.itely#newcode1134
Documentation/notation/fretted-strings.itely:1134: The file
@file{predefined-ukulele-fretboards.ly} contains the fret
I'm not a fan of this change. I'd rather have a manual line-break on
its own line:
... are contained in the file
@*
@file{blah}
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/fretted-strings.itely#newcode1404
Documentation/notation/fretted-strings.itely:1404:
@file{ly/predefined-guitar-fretboards.ly}, @*
oh god. Seriously?! there _has_ to be a better way to make tex behave.
hmm, maybe these could be wrapped in an @example? it's icky, though.
Not a serious suggestion.
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/input.itely#newcode1359
Documentation/notation/input.itely:1359:
@lilypond[verbatim,papersize=a8landscape]
why is this necessary? Does lilypond-book not select the appropriate
paper size when there's a \book{} inside the example? If that's the
case, it should be solved with lilypond-book, not by manually changing
every @lilypond that involves \book.
(this sounds slightly familiar. Didn't we have a round of bugfixes in
lilypond-book on this problem?)
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
http://codereview.appspot.com/6345088/diff/1/Documentation/notation/notation-appendices.itely#newcode48
Documentation/notation/notation-appendices.itely:48: @c The line width
is a hack to allow space for instrument names
I really don't like seeing hacks like this in the docs; it's just
wall-papering over flaws in lilypond itself. There should be a way to
tell lilypond "you have this much width on the page", and then lilypond
should select an appropriate line-width for the first line of the score
in order to have enough space for the instrument names.
http://codereview.appspot.com/6345088/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
- Original Message -
From:
To: ; ;
;
Cc: ;
Sent: Wednesday, July 11, 2012 4:23 PM
Subject: Re: Fixes all 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-headword.ly#newcode16
Documentation/snippets/simultaneous-headword.ly:16:
#'((alignment-distances .(12)))
Why removing the space after the dot?
There were hundreds of instances of notename space slur like c4 (. Our
style guide says there should be no space like c4(. I automatically
replaced " (" with "(" and the ". 12" was a victim. I spotted it and
corrected it in the online snippet and my system, but I forgot to amend my
commit. Thanks for checking.
http://codereview.appspot.com/6345088/
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all 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-headword.ly#newcode16 Documentation/snippets/simultaneous-headword.ly:16: #'((alignment-distances .(12))) Why removing the space after the dot? http://codereview.appspot.com/6345088/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes all black bars in NR (issue 6345088)
LGTM Trevor http://codereview.appspot.com/6345088/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fixes all black bars in NR (issue 6345088)
Reviewers: Graham Percival, Trevor Daniels, J_lowe, Message: Lots of changes here. The NR still builds successfully following them all, so I'm fairly confident, but please review if you have time. Description: Just a few changed files. A number of these are in /snippets and I have updated the LSR to match them already - these are just to illustrate the changes work. These changes get rid of all instances of 'overfull hbox' in the texi2pdf logfile and therefore of all the black sidebars caused by this. In a few places I've been forced to use new lines and fiddle image widths - the latter because of issue 766. Please review this at http://codereview.appspot.com/6345088/ Affected files: M Documentation/included/chord-names-jazz.ly M Documentation/included/display-predefined-fretboards.ly M Documentation/notation/ancient.itely M Documentation/notation/changing-defaults.itely M Documentation/notation/chords.itely M Documentation/notation/fretted-strings.itely M Documentation/notation/input.itely M Documentation/notation/notation-appendices.itely M Documentation/notation/pitches.itely M Documentation/notation/repeats.itely M Documentation/notation/simultaneous.itely M Documentation/notation/spacing.itely M Documentation/notation/staff.itely M Documentation/notation/wind.itely M Documentation/notation/world.itely M Documentation/snippets/ancient-headword.ly M Documentation/snippets/changing-the-breath-mark-symbol.ly M Documentation/snippets/chant-or-psalms-notation.ly M Documentation/snippets/chords-headword.ly M Documentation/snippets/editorial-headword.ly M Documentation/snippets/expressive-headword.ly M Documentation/snippets/figured-bass-headword.ly M Documentation/snippets/fretted-headword.ly M Documentation/snippets/making-some-staff-lines-thicker-than-the-others.ly M Documentation/snippets/new/chant-or-psalms-notation.ly M Documentation/snippets/new/chords-headword.ly M Documentation/snippets/new/fretted-headword.ly M Documentation/snippets/new/staff-headword.ly M Documentation/snippets/simultaneous-headword.ly M Documentation/snippets/staff-headword.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
