On 2012/08/10 07:54:51, Trevor Daniels wrote:
On 2012/08/09 07:36:46, Trevor Daniels wrote:
> Changed level 5 headings to @subsubheading @i{ .. }
These look fine to me in both pdf and html, so I'm
closing this review. I'll open a new issue tracker
to cover using level 5 headings uniformly.
On 2012/08/09 07:36:46, Trevor Daniels wrote:
Changed level 5 headings to @subsubheading @i{ .. }
These look fine to me in both pdf and html, so I'm
closing this review. I'll open a new issue tracker
to cover using level 5 headings uniformly.
Trevor
http://codereview.appspot.com/6452072/
Changed level 5 headings to @subsubheading @i{ .. }
and pushed directly to staging as
bc573af397a1b54f35fb1f95b3ee2e5360d4152f
If these look ok on grenouille I'll open a new issue
to track down and change all other occurrences of
level 5 headings and update the CG.
Trevor
http://codereview.app
On 2012/08/08 18:58:08, Trevor Daniels wrote:
On 2012/08/07 21:19:00, Trevor Daniels wrote:
> Leaving open until pdf has been checked
In the pdf all the headings below subsection are in the
same typeface, so it makes no difference to the pdf what
we do for these level 5 headings.
In html
On 2012/08/07 21:19:00, Trevor Daniels wrote:
Leaving open until pdf has been checked
In the pdf all the headings below subsection are in the
same typeface, so it makes no difference to the pdf what
we do for these level 5 headings.
In html they are all in differently sized fonts, but
using @
Pushed to staging as
593d611c5f63f3fedadf299e124a83ca4a709fe6
Leaving open until pdf has been checked
http://codereview.appspot.com/6452072/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
OK, I think we've arrived at an acceptable solution,
albeit via a somewhat circuitous route, posted as patch
set 2.
I'll wait to see how this looks in the pdf version and
if all is well I'll add this recipe to the CG and change
the couple of other places where this level of structuring
is used.
On 2012/08/04 15:11:55, Trevor Daniels wrote:
On 2012/08/04 09:33:33, dak wrote:
I'm sorry - I completely missed this. Probably because
I was hung up by the earlier sneer and didn't take in
much else. Since you ask, the bit that affected me was
> A heading indented as opposed to the follo
On 2012/08/04 09:33:33, dak wrote:
I don't see that ignoring even the proposal to use
a combination of structuring commands with explicit
markup is "the best course available".
I'm sorry - I completely missed this. Probably because
I was hung up by the earlier sneer and didn't take in
much el
On 2012/08/04 09:20:57, Trevor Daniels wrote:
On 2012/08/04 08:27:10, dak wrote:
> But again: the real issue to me seems that we are
> hiding a long chapter inside of a subsubsec already.
I agree. But to fix that would require rewriting pretty
well the whole of chapter 1 of the NR. I'm no
On 2012/08/04 08:27:10, dak wrote:
But again: the real issue to me seems that we are
hiding a long chapter inside of a subsubsec already.
I agree. But to fix that would require rewriting pretty
well the whole of chapter 1 of the NR. I'm not going to
do that. Let's just fix this simple issue
On 2012/08/04 08:06:38, Trevor Daniels wrote:
On 2012/08/03 09:35:47, dak wrote:
> The obvious way would be to reorganize into fewer layers.
No. This is a long and complicated subsubsec
Reorganizing into fewer layers would mean reorganizing the containing
structure so that we don't alrea
On 2012/08/03 09:35:47, dak wrote:
The obvious way would be to reorganize into fewer layers.
No. This is a long and complicated subsubsec and the point
of this issue is to improve clarity. The best way of doing
that is to introduce structure into the very long text. In
particular we need to
On 2012/08/03 09:30:55, Graham Percival wrote:
LGTM although I'm not wild about the @i{} bits, I can't immediately
think of a
better alternative.
The obvious way would be to reorganize into fewer layers. Nobody is
going to keep track of that many anyway.
That @i{} stuff is not really good:
LGTM although I'm not wild about the @i{} bits, I can't immediately
think of a better alternative.
http://codereview.appspot.com/6452072/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
In vocal.itely both @subheading and @subsubheading are used.
The CG advice is to use @subheading.
Both have disadvantages:
@subheading looks like @unnumberedsubsubsec
@subsubheading looks like Known issues and warnings et al.
So maybe @i{@strong .. }} is not so bad after all, at least
in its
Reviewers: ,
Message:
For Graham, really:
http://codereview.appspot.com/6452072/diff/1/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):
http://codereview.appspot.com/6452072/diff/1/Documentation/notation/rhythms.itely#newcode2007
Documentation/notation/rh
17 matches
Mail list logo
