Re: Lines to edges of \center-column

2017-04-24 Thread David Wright
On Mon 24 Apr 2017 at 21:35:48 (+0200), caag...@gmail.com wrote:
> Seems the latest devel version (2.19.59) has fixed that bug, so it's
> probably not important anymore.
> 
> On 04/24/17 19:43, David Wright wrote:
> >Well, I can't take a view on that because AFAICT the source in the OP
> >only contained kanji (complicated-looking) characters. Would that be
> >correct? Could you give the source with which you produced your
> >seam.png output (preferably as an attachment so I don't have to rely
> >on my paste's behaviour).
> 
> Sure, attached. (The two japanese words are "kana" and "kanji".)
> >I agree, but I'm more concerned about the contents of the window than
> >the window itself.
> 
> That's true, but ugly chrome can be rather distracting.

I don't know what chrome is.

> >Well, I've taken a closer look with evince at my box.pdf and I can see
> >the effect you mention. However, I think they're just artifacts of its
> >display, because when you magnify the areas in question, the blemishes
> >don't get magnified but disappear, or appear elsewhere. So I don't
> >think the problem lies in the PDF at all. One also has to bear in mind
> >that the screen resolution can lead to odd effects just because of
> >where the grid of pixels happen to be relative to the image.
> 
> Yeah, I'm pretty sure those gaps are just some kind of rounding error.
> 
> >Are those characters the same height? I think you should put some
> >characters into both lines for control purposes; some ordinary Roman
> >alphabeticals, say.
> 
> I'm pretty sure they are, assuming they use the same font. Oddly
> enough, manually specifying the font fixes it (tested with Takao
> Gothic and Takao Mincho). The Japanese characters look identical
> with and without manual font override, but the boxes don't.
> 
> I'm guessing it's just some weird font bug, which is fixed in 2.19.

Looking back at your seam.png, and at my output from the modified LP
that you posted, I would guess that different fonts were used for the
two lines. Now the actual thicknesses aren't defined, though HEAVY
will presumably be at least as thick as normal. But what might affect
you is if one of your fonts is, for some reason, doing some sort of
double-width operation.

IOW is it possible that something looks at a double-width font
and decides to pull out the matching double-width box characters
to put alongside it? This decision could have been made differently
for the two fonts/character sets you were using, hence one set of
lines being roughly twice as long as the other. The easiest way
to test this might be with box characters that are not just simple
horizontals, ie using characters like ┳ and ╔.

> By the way, is it possible to have both 2.18 and 2.19 installed at
> the same time (preferrably with 2.19 as the default `lilypond`), on
> Arch Linux? Having to uninstall and then recompile if I want to test
> something with 2.18 isn't very fun.

Yes. I don't know which version Arch installs itself, but you can
install as many versions of LP as you like so long as you use prefixes
to distinguish them. Here's my crib for installation. Obviously you
don't uninstall the others if you want several.

✁✂✁✂✁✂✁✂
Uninstall the old development version:

$ (bash) /home/david/lilypond-xxxoldxxx/bin/uninstall-lilypond

This does not remove links in ~/bin, or the ~/bin/lilypond executable,
because of the copying shown below.

Install the newly downloaded one:

$ cd ~
$ bash .../lilypond-xxxnewxxx.linux-x86.sh --prefix lilypond-xxxnewxxx

Copy links in ~/lilypond-xxxnewxxx/bin/ and  ~/lilypond-xxxnewxxx/bin/lilypond
into ~/bin/, overwriting the old ones there.
✃✂✃✂✃✂✃✂

~/bin/ is in my $PATH, of course, which handles my defaulting version,
but you can use the various versions ~/lilypond-xxxnewxxx/bin/lilypond
directly, or give them more convenient aliases.

Cheers,
David.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-24 Thread caagr98
Seems the latest devel version (2.19.59) has fixed that bug, so it's 
probably not important anymore.


On 04/24/17 19:43, David Wright wrote:

Well, I can't take a view on that because AFAICT the source in the OP
only contained kanji (complicated-looking) characters. Would that be
correct? Could you give the source with which you produced your
seam.png output (preferably as an attachment so I don't have to rely
on my paste's behaviour).


Sure, attached. (The two japanese words are "kana" and "kanji".)

I agree, but I'm more concerned about the contents of the window than
the window itself.


That's true, but ugly chrome can be rather distracting.


Well, I've taken a closer look with evince at my box.pdf and I can see
the effect you mention. However, I think they're just artifacts of its
display, because when you magnify the areas in question, the blemishes
don't get magnified but disappear, or appear elsewhere. So I don't
think the problem lies in the PDF at all. One also has to bear in mind
that the screen resolution can lead to odd effects just because of
where the grid of pixels happen to be relative to the image.


Yeah, I'm pretty sure those gaps are just some kind of rounding error.


Are those characters the same height? I think you should put some
characters into both lines for control purposes; some ordinary Roman
alphabeticals, say.


I'm pretty sure they are, assuming they use the same font. Oddly enough, 
manually specifying the font fixes it (tested with Takao Gothic and 
Takao Mincho). The Japanese characters look identical with and without 
manual font override, but the boxes don't.


I'm guessing it's just some weird font bug, which is fixed in 2.19.

By the way, is it possible to have both 2.18 and 2.19 installed at the 
same time (preferrably with 2.19 as the default `lilypond`), on Arch 
Linux? Having to uninstall and then recompile if I want to test 
something with 2.18 isn't very fun.
\version "2.18.2"
\paper {
  #(define fonts
 (make-pango-font-tree "Takao Gothic" "" ""
   (/ staff-height pt 20)))
}
\markup {
  "かな━━━"
}
\markup {
  "漢字━━━"
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-24 Thread David Wright
On Sun 23 Apr 2017 at 04:12:32 (+0200), caag...@gmail.com wrote:
> On 04/23/17 03:47, David Wright wrote:
> >Then I don't know what you mean. When you drag over them, they turn
> >blue because you _have_ selected them (drag.png, apologies for the
> >size). Then you can paste them into, say, a bash shell command line
> >(pasted.png, the box at the right is the inactive cursor).
> 
> The top (kana) line can't be selected at all, is what I'm trying to
> say. It acts a bit different in different viewers, but none seem to
> be able to select+copy it.

Well, I can't take a view on that because AFAICT the source in the OP
only contained kanji (complicated-looking) characters. Would that be
correct? Could you give the source with which you produced your
seam.png output (preferably as an attachment so I don't have to rely
on my paste's behaviour).

> >But why do you want to select part of a PDF like that when _you_
> >generated it? I often do that with _other_ people's PDFs when I
> >want to get at their text.
> 
> It's not that I want to select it, it's just that I hate when things
> are inconsistent like that.
> 
> >The rendition of the dragged area is entirely a function of the
> >viewer you're using. Xpdf always shows a rectangle and lifts
> >just the text therein, rather than being constrained by the lines
> >of text (xpdf.png, more apologies). However, I think it mixes up
> >its encodings so the pasted text makes little sense.
> >
> >That looks a lot like evince that you're using. Very good for reading
> >Chase credit card statements and encrypted PDFs, which xpdf can't
> >manage, but I hate the interface.
> 
> It's actually Atril, MATE's Evince fork. I use it because it
> respects my GTK theme, and unlike Evince, it doesn't use client-side
> window decorations, so it works with i3. I think xpdf's UI looks
> horrible, btw. Its rendering quality seems good, though.

I agree, but I'm more concerned about the contents of the window than
the window itself.

> >Anyway, my guess is that evince
> >treats keeping the characters _as_ individual characters as its
> >priority, whereas xpdf tries to render what will print.
> 
> Yeah, I've noticed that Atril often renders things slightly
> differently when zoomed-out.
> 
> >One really needs an armoury of PDF viewers.
> 
> And yet, PDF's main point is that it looks identical on all devices...

Well, I've taken a closer look with evince at my box.pdf and I can see
the effect you mention. However, I think they're just artifacts of its
display, because when you magnify the areas in question, the blemishes
don't get magnified but disappear, or appear elsewhere. So I don't
think the problem lies in the PDF at all. One also has to bear in mind
that the screen resolution can lead to odd effects just because of
where the grid of pixels happen to be relative to the image.

When I wrote armoury, I really meant in terms of their functionality
rather than differences in the document display. Xpdf has flexible
navigation (by page, by 10 pages, by history, and by pagenumber),
zoom (width, height, entire page, selected area), rotation, page/
continuous view, 'q' to quit, and so on. Evince can handle some PDFs
that xpdf can't, as mentioned before, but also view different types
of document. Xournal can annotate PDFs with text and drawings. Etc.
But the PDFs all look the same.

> >So now the question becomes what do you want to produce these PDFs
> >for, and how are you going to ascertain which browser the consumers
> >are using? If I were sending them to my printers, my expectations
> >(and theirs) would be the sort of copies that I've shown magnified.
> 
> That kind of minutiae doesn't bother me very much (only a
> little...); the big problem is that the lines on the kana row and
> the kanji row are different shapes. They're both three box-drawings
> on each side, but they look quite different in all PDF viewers I've
> tried (Firefox, Chromium, Atril, Okular, xpdf).

Are those characters the same height? I think you should put some
characters into both lines for control purposes; some ordinary Roman
alphabeticals, say.

> Also, I wouldn't say 70kb is much to apologize for.

I meant screen size rather then file size. I usually select the area
of my screenshots (like pasted.png), but I needed to use my
delayed-screenshot button to capture evince's and xpdf's own selection
correctly; you can't drag a mouse to select an area over an already
active mouse selection without destroying the latter.

Cheers,
David.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread David Nalesnik
On Sat, Apr 22, 2017 at 5:56 PM,   wrote:
> This is great, thanks! I was trying to mess around with \hbracket and
> \whiteout, but this is far better.
>
> Just a few questions:
> Is it possible to scale the protrusions (and other things) by font size?
> How can I change the color of the lines?
> What does "mols" mean?

I'd guess "molecules," referring here to stencils.  I've seen "atom"
used in Scheme programming.  In any case, I just copied from the
source.

Looks like you answered your other questions below

Best,
David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread caagr98
I did some further work on it. It looks pretty great, IMO. It works with left- 
and right-aligning, too. No scaling horizontally (just 1sp margins), but it 
automatically scales vertically.

```
#(define (expand-add pair n)
   (cons (- (car pair) n) (+ (cdr pair) n)))
#(define (expand-mul mul pair)
   (let* ((a (car pair))
  (b (cdr pair))
  (mid (/ (+ a b) 2))
  (A (+ (* (- a mid) mul) mid))
  (B (+ (* (- b mid) mul) mid)))
 (cons A B)))

#(define (add-brackets mols th)
   (define (line x1 y1 x2 y2)
 (stencil-with-color
  (make-line-stencil th x1 y1 x2 y2)
  '(3/5 3/5 3/5)))
   (let ((max-extent (ly:stencil-extent (car mols) X)))
 (map (lambda (x)
(let ((stil-ext (ly:stencil-extent x X)))
  (if (not (equal? max-extent stil-ext))
  (let ((me (expand-add max-extent -2))
(se (expand-add stil-ext 1))
(ye (expand-mul 1/2 (ly:stencil-extent x Y
(if (< (car me) (car se))
(set! x
  (ly:stencil-add
   (line (car me) (car ye) (car se) (car ye))
   (line (car me) (car ye) (car me) (cdr ye))
   x)))
(if (> (cdr me) (cdr se))
(set! x
  (ly:stencil-add
   (line (cdr se) (car ye) (cdr me) (car ye))
   (line (cdr me) (car ye) (cdr me) (cdr ye))
   x))
x)
  mols)))

#(define (general-column-bracket align-dir baseline mols)
   (let* ((aligned-mols (map (lambda (x) (ly:stencil-aligned-to x X align-dir)) 
mols))
  (aligned-mols (add-brackets aligned-mols 0.1))
  (stacked-stencil (stack-lines -1 0.0 baseline aligned-mols))
  (stacked-extent (ly:stencil-extent stacked-stencil X)))
 (ly:stencil-translate-axis stacked-stencil (- (car stacked-extent)) X)))

#(define-markup-command (jp-column layout props args)
   (markup-list?)
   #:category align
   #:properties ((baseline-skip))
   (general-column-bracket CENTER baseline-skip (interpret-markup-list layout 
props args)))
```

On 04/23/17 00:56, caag...@gmail.com wrote:
> This is great, thanks! I was trying to mess around with \hbracket and 
> \whiteout, but this is far better.
> 
> Just a few questions:
> Is it possible to scale the protrusions (and other things) by font size?
> How can I change the color of the lines?
> What does "mols" mean?
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread caagr98

On 04/23/17 03:47, David Wright wrote:

Then I don't know what you mean. When you drag over them, they turn
blue because you _have_ selected them (drag.png, apologies for the
size). Then you can paste them into, say, a bash shell command line
(pasted.png, the box at the right is the inactive cursor).


The top (kana) line can't be selected at all, is what I'm trying to say. 
It acts a bit different in different viewers, but none seem to be able 
to select+copy it.



But why do you want to select part of a PDF like that when _you_
generated it? I often do that with _other_ people's PDFs when I
want to get at their text.


It's not that I want to select it, it's just that I hate when things are 
inconsistent like that.



The rendition of the dragged area is entirely a function of the
viewer you're using. Xpdf always shows a rectangle and lifts
just the text therein, rather than being constrained by the lines
of text (xpdf.png, more apologies). However, I think it mixes up
its encodings so the pasted text makes little sense.

That looks a lot like evince that you're using. Very good for reading
Chase credit card statements and encrypted PDFs, which xpdf can't
manage, but I hate the interface.


It's actually Atril, MATE's Evince fork. I use it because it respects my 
GTK theme, and unlike Evince, it doesn't use client-side window 
decorations, so it works with i3. I think xpdf's UI looks horrible, btw. 
Its rendering quality seems good, though.



Anyway, my guess is that evince
treats keeping the characters _as_ individual characters as its
priority, whereas xpdf tries to render what will print.


Yeah, I've noticed that Atril often renders things slightly differently 
when zoomed-out.



One really needs an armoury of PDF viewers.


And yet, PDF's main point is that it looks identical on all devices...


So now the question becomes what do you want to produce these PDFs
for, and how are you going to ascertain which browser the consumers
are using? If I were sending them to my printers, my expectations
(and theirs) would be the sort of copies that I've shown magnified.


That kind of minutiae doesn't bother me very much (only a little...); 
the big problem is that the lines on the kana row and the kanji row are 
different shapes. They're both three box-drawings on each side, but they 
look quite different in all PDF viewers I've tried (Firefox, Chromium, 
Atril, Okular, xpdf).


Also, I wouldn't say 70kb is much to apologize for.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread David Wright
On Sun 23 Apr 2017 at 02:09:34 (+0200), caag...@gmail.com wrote:
> 
> 
> On 04/23/17 01:53, David Wright wrote:
> >I tried to provoke a problem, but I don't know my kanji from my kana,
> >and am not sure what you mean by "selectable".
> 
> I mean they're marked in blue by ctrl-A or dragging (selected.png).

Then I don't know what you mean. When you drag over them, they turn
blue because you _have_ selected them (drag.png, apologies for the
size). Then you can paste them into, say, a bash shell command line
(pasted.png, the box at the right is the inactive cursor).

But why do you want to select part of a PDF like that when _you_
generated it? I often do that with _other_ people's PDFs when I
want to get at their text.

The rendition of the dragged area is entirely a function of the
viewer you're using. Xpdf always shows a rectangle and lifts
just the text therein, rather than being constrained by the lines
of text (xpdf.png, more apologies). However, I think it mixes up
its encodings so the pasted text makes little sense.

> >The greatest zoom I can manage is 1600%, and I can't see the joins.
> >The H bars were just to follow each of your characters with something.
> 
> I'm pretty sure it's just some kind of rounding error in my PDF
> viewer, but you can see a seam between the first and second bar to
> right of the kanji in the second row (seam.png).
> 
> Also note that the bars on the kana row are a lot longer and thinner
> than the kanji row.

That looks a lot like evince that you're using. Very good for reading
Chase credit card statements and encrypted PDFs, which xpdf can't
manage, but I hate the interface. Anyway, my guess is that evince
treats keeping the characters _as_ individual characters as its
priority, whereas xpdf tries to render what will print.
One really needs an armoury of PDF viewers.

So now the question becomes what do you want to produce these PDFs
for, and how are you going to ascertain which browser the consumers
are using? If I were sending them to my printers, my expectations
(and theirs) would be the sort of copies that I've shown magnified.

Cheers,
David.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread caagr98



On 04/23/17 01:53, David Wright wrote:

I tried to provoke a problem, but I don't know my kanji from my kana,
and am not sure what you mean by "selectable".


I mean they're marked in blue by ctrl-A or dragging (selected.png).


The greatest zoom I can manage is 1600%, and I can't see the joins.
The H bars were just to follow each of your characters with something.


I'm pretty sure it's just some kind of rounding error in my PDF viewer, 
but you can see a seam between the first and second bar to right of the 
kanji in the second row (seam.png).


Also note that the bars on the kana row are a lot longer and thinner 
than the kanji row.


```
\version "2.18.2"
\markup "━━━かな━━━" %kana
\markup "━━━漢字━━━" %kanji
```
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread caagr98
This is great, thanks! I was trying to mess around with \hbracket and 
\whiteout, but this is far better.


Just a few questions:
Is it possible to scale the protrusions (and other things) by font size?
How can I change the color of the lines?
What does "mols" mean?


On 04/23/17 00:34, David Nalesnik wrote:

On Sat, Apr 22, 2017 at 3:22 PM,   wrote:

Is there some way to make a center-column draw lines from slightly outside
the text to the edges of the column (see example)?

In this specific case, I have both English and Japanese names for stuff, and
without those lines, I think it's a bit unclear exactly what part the
Japanese refers to.

```
subtitle = \markup \bold \large \line {
   "from"
   \center-column {
 "Legend of Heroes"
 \smaller \smaller \smaller
 "英雄伝説"
   }
   "VI:"
   \center-column {
 "Trails in the Sky"
 \smaller \smaller \smaller
 "空の軌跡"
   }
}
```


Try this:

\version "2.19.59"

% based on general-column from scm/define-markup-commands.scm
#(define (general-column align-dir baseline mols)
(let* ((aligned-mols
(map (lambda (x) (ly:stencil-aligned-to x X align-dir))
  mols))
   (max-extent (ly:stencil-extent (car aligned-mols) X))
   (aligned-mols
(cons (car aligned-mols)
  (map (lambda (x)
 (let ((stil-ext (ly:stencil-extent x X)))
   (ly:stencil-add
(make-line-stencil 0.1 (car max-extent) 0 (1-
(car stil-ext)) 0)
(make-line-stencil 0.1 (1+ (cdr stil-ext)) 0
(cdr max-extent) 0)
(make-line-stencil 0.1 (car max-extent) 0 (car
max-extent) 1.5)
(make-line-stencil 0.1 (cdr max-extent) 0 (cdr
max-extent) 1.5)
x)))
(cdr aligned-mols
   (stacked-stencil (stack-lines -1 0.0 baseline aligned-mols))
   (stacked-extent (ly:stencil-extent stacked-stencil X)))
  (ly:stencil-translate-axis stacked-stencil (- (car stacked-extent)) X)))

#(define-markup-command (center-column layout props args)
(markup-list?)
#:category align
#:properties ((baseline-skip))
(general-column CENTER baseline-skip (interpret-markup-list layout
props args)))

\header {
   subtitle = \markup \bold \large \line {
 "from"
 \center-column {
   "Legend of Heroes"
   \smaller \smaller \smaller
   "英雄伝説"
   "英雄伝説"
   \huge
   "英雄伝説"
 }
 "VI:"
 \center-column {
   "Trails in the Sky"
   \smaller \smaller \smaller
   "空の軌跡"
 }
   }
}

{ c }

You might want to adjust some of the hard-coded values
(line-thickness, length of "protrusions," offset of bracket from
text), but this should get you started.

-David



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread Thomas Morley
2017-04-23 0:34 GMT+02:00 David Nalesnik :
> On Sat, Apr 22, 2017 at 3:22 PM,   wrote:
>> Is there some way to make a center-column draw lines from slightly outside
>> the text to the edges of the column (see example)?
>>
>> In this specific case, I have both English and Japanese names for stuff, and
>> without those lines, I think it's a bit unclear exactly what part the
>> Japanese refers to.
>>
>> ```
>> subtitle = \markup \bold \large \line {
>>   "from"
>>   \center-column {
>> "Legend of Heroes"
>> \smaller \smaller \smaller
>> "英雄伝説"
>>   }
>>   "VI:"
>>   \center-column {
>> "Trails in the Sky"
>> \smaller \smaller \smaller
>> "空の軌跡"
>>   }
>> }
>> ```
>
> Try this:
>
> \version "2.19.59"
>
> % based on general-column from scm/define-markup-commands.scm
> #(define (general-column align-dir baseline mols)
>(let* ((aligned-mols
>(map (lambda (x) (ly:stencil-aligned-to x X align-dir))
>  mols))
>   (max-extent (ly:stencil-extent (car aligned-mols) X))
>   (aligned-mols
>(cons (car aligned-mols)
>  (map (lambda (x)
> (let ((stil-ext (ly:stencil-extent x X)))
>   (ly:stencil-add
>(make-line-stencil 0.1 (car max-extent) 0 (1-
> (car stil-ext)) 0)
>(make-line-stencil 0.1 (1+ (cdr stil-ext)) 0
> (cdr max-extent) 0)
>(make-line-stencil 0.1 (car max-extent) 0 (car
> max-extent) 1.5)
>(make-line-stencil 0.1 (cdr max-extent) 0 (cdr
> max-extent) 1.5)
>x)))
>(cdr aligned-mols
>   (stacked-stencil (stack-lines -1 0.0 baseline aligned-mols))
>   (stacked-extent (ly:stencil-extent stacked-stencil X)))
>  (ly:stencil-translate-axis stacked-stencil (- (car stacked-extent)) X)))
>
> #(define-markup-command (center-column layout props args)
>(markup-list?)
>#:category align
>#:properties ((baseline-skip))
>(general-column CENTER baseline-skip (interpret-markup-list layout
> props args)))
>
> \header {
>   subtitle = \markup \bold \large \line {
> "from"
> \center-column {
>   "Legend of Heroes"
>   \smaller \smaller \smaller
>   "英雄伝説"
>   "英雄伝説"
>   \huge
>   "英雄伝説"
> }
> "VI:"
> \center-column {
>   "Trails in the Sky"
>   \smaller \smaller \smaller
>   "空の軌跡"
> }
>   }
> }
>
> { c }
>
> You might want to adjust some of the hard-coded values
> (line-thickness, length of "protrusions," offset of bracket from
> text), but this should get you started.
>
> -David
>

Here my approach:

#(define-markup-command (single-hbracket-with-text layout props ref arg)
  (markup? markup?)
  #:properties ((thick 0.1)
(protrusion 1)
(dir 1)
(axis X))
"Prints a bracket overlayed by @code{arg}. Both are center-aligned.

Takes the bracket-ext from @var{ref} in direction of the @code{axis}-property.
The angles of the bracket are printed in direction of the @code{dir}-property.
The appearance is tweakable with overrides for @code{thick} and
@code{protrusion}."

  (define (bracket-stencil stil axis thick protrusion dir)
   (let* ((ext (ly:stencil-extent stil axis))
  (lb (ly:bracket axis ext thick protrusion))
  (rb (ly:bracket axis ext thick (- protrusion
 (if (= 1 dir) lb rb)))

  (let* ((stil (interpret-markup layout props ref)))
(ly:stencil-add
  (ly:stencil-aligned-to
(bracket-stencil stil axis thick protrusion dir) axis CENTER)
  (ly:stencil-aligned-to
(interpret-markup layout props arg) axis CENTER



\markup \bold \large \line {
  "from"
  \override #'(baseline-skip . 1)
  \center-column {
"Legend of Heroes"
\single-hbracket-with-text
  "Legend of Heroes"
  \whiteout \vcenter \smaller \smaller \smaller \pad-x #0.3 "英雄伝説"
  }
  "VI:"
  \override #'(baseline-skip . 1)
  \center-column {
"Trails in the Sky"
\single-hbracket-with-text
  "Trails in the Sky"
  \whiteout \vcenter \smaller \smaller \smaller \pad-x #0.3 "空の軌跡"
  }
}


It needs a ref-markup for the bracket-extent and the text is overlayed
with control-possibilities for the user.
Didn't want to do too much automatically.


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread David Wright
On Sun 23 Apr 2017 at 00:03:36 (+0200), caag...@gmail.com wrote:
> That's certainly a possibility, it's not working too well. I have to
> do the alignment manually, and I can't change the line style. Also,
> it's a bit buggy: putting box-drawers after kanji works fine, but if
> it's after a kana, it's not selectable, and it has a different
> width. There are also small gaps between the segments at certain
> zoom levels.
> 
> I think \fill-with-pattern seems somewhat related to what I want,
> but I'm guessing that one's implemented natively?
> 
> P.S. I think you're exaggerating with the encoding details.

I just pasted the output from
http://www.ltg.ed.ac.uk/~richard/utf-8.cgi?input=%E2%94%81=char

> On 04/22/17 23:46, David Wright wrote:
> >On Sat 22 Apr 2017 at 22:22:30 (+0200), caag...@gmail.com wrote:
> >>Is there some way to make a center-column draw lines from slightly
> >>outside the text to the edges of the column (see example)?
> >>
> >>In this specific case, I have both English and Japanese names for
> >>stuff, and without those lines, I think it's a bit unclear exactly
> >>what part the Japanese refers to.
> >
> >You could just put Unicode box-drawing characters to either side
> >of the Japanese characters, eg ━ is BOX DRAWINGS HEAVY HORIZONTAL
> >but there are various weights, and corners etc in the same region
> >as this one (Hex code point 2501, Decimal code point 9473,
> >Hex UTF-8 bytes E2 94 81, Octal UTF-8 bytes 342 224 201,
> >UTF-8 bytes as Latin-1 characters bytes â <94> <81>
> >)

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread David Nalesnik
On Sat, Apr 22, 2017 at 3:22 PM,   wrote:
> Is there some way to make a center-column draw lines from slightly outside
> the text to the edges of the column (see example)?
>
> In this specific case, I have both English and Japanese names for stuff, and
> without those lines, I think it's a bit unclear exactly what part the
> Japanese refers to.
>
> ```
> subtitle = \markup \bold \large \line {
>   "from"
>   \center-column {
> "Legend of Heroes"
> \smaller \smaller \smaller
> "英雄伝説"
>   }
>   "VI:"
>   \center-column {
> "Trails in the Sky"
> \smaller \smaller \smaller
> "空の軌跡"
>   }
> }
> ```

Try this:

\version "2.19.59"

% based on general-column from scm/define-markup-commands.scm
#(define (general-column align-dir baseline mols)
   (let* ((aligned-mols
   (map (lambda (x) (ly:stencil-aligned-to x X align-dir))
 mols))
  (max-extent (ly:stencil-extent (car aligned-mols) X))
  (aligned-mols
   (cons (car aligned-mols)
 (map (lambda (x)
(let ((stil-ext (ly:stencil-extent x X)))
  (ly:stencil-add
   (make-line-stencil 0.1 (car max-extent) 0 (1-
(car stil-ext)) 0)
   (make-line-stencil 0.1 (1+ (cdr stil-ext)) 0
(cdr max-extent) 0)
   (make-line-stencil 0.1 (car max-extent) 0 (car
max-extent) 1.5)
   (make-line-stencil 0.1 (cdr max-extent) 0 (cdr
max-extent) 1.5)
   x)))
   (cdr aligned-mols
  (stacked-stencil (stack-lines -1 0.0 baseline aligned-mols))
  (stacked-extent (ly:stencil-extent stacked-stencil X)))
 (ly:stencil-translate-axis stacked-stencil (- (car stacked-extent)) X)))

#(define-markup-command (center-column layout props args)
   (markup-list?)
   #:category align
   #:properties ((baseline-skip))
   (general-column CENTER baseline-skip (interpret-markup-list layout
props args)))

\header {
  subtitle = \markup \bold \large \line {
"from"
\center-column {
  "Legend of Heroes"
  \smaller \smaller \smaller
  "英雄伝説"
  "英雄伝説"
  \huge
  "英雄伝説"
}
"VI:"
\center-column {
  "Trails in the Sky"
  \smaller \smaller \smaller
  "空の軌跡"
}
  }
}

{ c }

You might want to adjust some of the hard-coded values
(line-thickness, length of "protrusions," offset of bracket from
text), but this should get you started.

-David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread caagr98
That's certainly a possibility, it's not working too well. I have to do 
the alignment manually, and I can't change the line style. Also, it's a 
bit buggy: putting box-drawers after kanji works fine, but if it's after 
a kana, it's not selectable, and it has a different width. There are 
also small gaps between the segments at certain zoom levels.


I think \fill-with-pattern seems somewhat related to what I want, but 
I'm guessing that one's implemented natively?


P.S. I think you're exaggerating with the encoding details.

On 04/22/17 23:46, David Wright wrote:

On Sat 22 Apr 2017 at 22:22:30 (+0200), caag...@gmail.com wrote:

Is there some way to make a center-column draw lines from slightly
outside the text to the edges of the column (see example)?

In this specific case, I have both English and Japanese names for
stuff, and without those lines, I think it's a bit unclear exactly
what part the Japanese refers to.


You could just put Unicode box-drawing characters to either side
of the Japanese characters, eg ━ is BOX DRAWINGS HEAVY HORIZONTAL
but there are various weights, and corners etc in the same region
as this one (Hex code point 2501, Decimal code point 9473,
Hex UTF-8 bytes E2 94 81, Octal UTF-8 bytes 342 224 201,
UTF-8 bytes as Latin-1 characters bytes â <94> <81>
)

Cheers,
David.



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Lines to edges of \center-column

2017-04-22 Thread David Wright
On Sat 22 Apr 2017 at 22:22:30 (+0200), caag...@gmail.com wrote:
> Is there some way to make a center-column draw lines from slightly
> outside the text to the edges of the column (see example)?
> 
> In this specific case, I have both English and Japanese names for
> stuff, and without those lines, I think it's a bit unclear exactly
> what part the Japanese refers to.

You could just put Unicode box-drawing characters to either side
of the Japanese characters, eg ━ is BOX DRAWINGS HEAVY HORIZONTAL
but there are various weights, and corners etc in the same region
as this one (Hex code point 2501, Decimal code point 9473,
Hex UTF-8 bytes E2 94 81, Octal UTF-8 bytes 342 224 201,
UTF-8 bytes as Latin-1 characters bytes â <94> <81>
)

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user