Jean Abou Samra wrote:
[Robin]
The stroke width I see is 1px (Firefox at 100%). This makes the
stroke dominated by edge effects; the surrounding white dilutes its
colour.
Do the WCAG recommendations recognise this? If not, please don't
apply their levels to this case.
I don't know. I am
Hello Paul,
The documentation does not specify any fonts. It simply uses the and
tags. That means that the fonts used are whatever font your
browser chooses as default font, which on Windows systems appears to be
Courier for monospace and apparently in your case Georgia for the regular
Le 04/01/2022 à 11:35, Thomas Morley a écrit :
Am Di., 4. Jan. 2022 um 11:15 Uhr schrieb Paul McKay :
Hi
Speaking as someone whose eyesight isn't quite as good as it used to be,
Same problem here
I'd like to suggest that anything in a colour is also in bold so that there are
enough pixels
Le 04/01/2022 à 23:19, Aaron Hill a écrit :
On 2022-01-04 1:42 pm, Jean Abou Samra wrote:
https://www.gnu.org/philosophy/javascript-trap.en.html
[ . . . ]
But I'm probably fretting for something that is
very easy in the end.
The code Lilypond's site would use would be entirely homegrown,
Le 04/01/2022 à 00:33, David Kastrup a écrit :
Flaming Hakama by Elaine writes:
In this sense, it seems like the place that has the most potential use
for helping people distinguish different data types is where the
syntax is the most complicated and dense, which is in music entry.
The
On 2022-01-04 1:42 pm, Jean Abou Samra wrote:
https://www.gnu.org/philosophy/javascript-trap.en.html
[ . . . ]
But I'm probably fretting for something that is
very easy in the end.
The code Lilypond's site would use would be entirely homegrown, licensed
under GPL. Not sure there is anything
[Aaron]
On 2022-01-04 11:32 am, Jean Abou Samra wrote:
Always best to consult a lawyer on legal matters.
The wife of my cousin is actually a lawyer.
Sadly (but very happily in fact), she gave
birth yesterday, so she will not be in a position
to answer before a while :-)
My layman
On 04/01/2022 19:32, Jean Abou Samra wrote:
Forgive my igorance with the inner workings of the
Internet: what does this mean in connection with GDPR
and all that? Am I right that the fact that the
information stored on the user's device serves
a purpose essential to satisfying the very request
On 2022-01-04 11:32 am, Jean Abou Samra wrote:
Forgive my igorance with the inner workings of the
Internet: what does this mean in connection with GDPR
and all that? Am I right that the fact that the
information stored on the user's device serves
a purpose essential to satisfying the very
Hello Jean,
The code Aaron provided is quite nice, but I suggest to rather use a linked
stylesheet like
And then use JS like
document.getElementById("syntax-highlighting") = "highlighting1.css"
This results in less complicated JS and allows for multiple styles.
Cheers,
Valentin
Am
[Aaron]
It is fairly straightforward with CSS and a little JavaScript:
Yeah, that is also what I was starting to muse with
more seriously. Thanks for providing ready-made code.
Forgive my igorance with the inner workings of the
Internet: what does this mean in connection with GDPR
and all
On 2022-01-04 10:04 am, Valentin Petzel wrote:
The problem is that we probably want to
remember the set color scheme for longer than just the current page,
so we'd need something like cookies.
Not a problem in the slightest. But not cookies... localStorage [1].
[1]:
In fact it is sufficient to have multiple stylesheets and load the one you want
to switch to. The problem is that we probably want to remember the set color
scheme for longer than just the current page, so we'd need something like
cookies.
We could also do this without JS by generating
On 04/01/2022 16:23, Aaron Hill wrote:
On 2022-01-04 7:29 am, Erika Pirnes wrote:
Would it be terribly difficult to have a color setting on the
documentation page, so that people can choose between black and color?
It is fairly straightforward with CSS and a little JavaScript:
Is that on
On 04/01/2022 15:14, J Martin Rushton wrote:
OK, I'll admit I only skimmed it, hence "I've saved the paper to read
later"! I've got Doob's "A Gentle Introduction to TeX" and Oetiker's
"The Not So Short Introduction to LaTeX2e" both of which keep to the
fixed width convention. Again, I'll be
On 2022-01-04 7:29 am, Erika Pirnes wrote:
Would it be terribly difficult to have a color setting on the
documentation page, so that people can choose between black and color?
It is fairly straightforward with CSS and a little JavaScript:
Dynamic styles
body { font-size:
I personally find the black text much easier to read than the syntax-highlighed
one in colors. I still have young eyes, but somehow the colored text feels
tiring. Maybe this is just what I am used to, as I am still using the standard
text editor to write my .ly files. Would it be terribly
OK, I'll admit I only skimmed it, hence "I've saved the paper to read
later"! I've got Doob's "A Gentle Introduction to TeX" and Oetiker's
"The Not So Short Introduction to LaTeX2e" both of which keep to the
fixed width convention. Again, I'll be honest, I rarely use them since
I've retired
J Martin Rushton writes:
> Interesting Aaron, but I do note that the paper is from 1983 and didn't
> catch on. I wonder if there is a reason for that? I've saved the
> paper to read later. Personally I don't know of a single language that
> is happy with word processor output as source code,
Hello Robin,
as far as I know the Lilypond Documentation does not specify the font to be
used for this. So the system defaults to a standard monospace font.
So the font will depend on the system. We could ship a dedicated font with the
documentation, but I'm not sure if we want that.
Cheers,
Interesting Aaron, but I do note that the paper is from 1983 and didn't
catch on. I wonder if there is a reason for that? I've saved the
paper to read later. Personally I don't know of a single language that
is happy with word processor output as source code, but then I may be
proved wrong.
On 2022-01-04 4:19 am, J Martin Rushton wrote:
Sorry to disagree, but fixed pitch is _so_ much easier to lay out in an
editor. Documentation flows nicely with variable pitch and fancy
hidden formats, but for code (and Lily's input is a programming
language) you just want the plain line-by-line
Paul,
Sorry to disagree, but fixed pitch is _so_ much easier to lay out in an
editor. Documentation flows nicely with variable pitch and fancy
hidden formats, but for code (and Lily's input is a programming
language) you just want the plain line-by-line ASCII. It is, as you
say, industry
'Hear hear' to these recent posts from Thomas, Paul and the two Davids!
I don't object to the fixed width, but the code font has always been
spindly compared to the rest of the documentation text. I find this
makes it harder to read anyway.
The stroke width I see is 1px (Firefox at 100%).
Am Di., 4. Jan. 2022 um 11:15 Uhr schrieb Paul McKay :
>
> Hi
> Speaking as someone whose eyesight isn't quite as good as it used to be,
Same problem here
> I'd like to suggest that anything in a colour is also in bold so that there
> are enough pixels for me to see what the colour is.
I'd go
Hi
Speaking as someone whose eyesight isn't quite as good as it used to be,
I'd like to suggest that anything in a colour is also in bold so that there
are enough pixels for me to see what the colour is.
And this seems the appropriate place to ask why the examples are all in
fixed pitch Courier
Flaming Hakama by Elaine writes:
> In this sense, it seems like the place that has the most potential use
> for helping people distinguish different data types is where the
> syntax is the most complicated and dense, which is in music entry.
>
> The ability to quickly distinguish articulations,
>
> Am Sonntag, 2. Jänner 2022, 01:06:35 CET schrieb David Kastrup:
> > Jean Abou Samra writes:
> > > Hi all,
> > >
> > > There is an ongoing proposal to add syntax highlighting
> > > in LilyPond's documentation. Since it is a notable change
> > > to the documentation reading experience, user
Jean Abou Samra writes:
> Hi all,
>
> There is an ongoing proposal to add syntax highlighting
> in LilyPond's documentation. Since it is a notable change
> to the documentation reading experience, user feedback would
> be appreciated. You can browse a syntax-highlighted version
> of the notation
lilypond-user-ow...@gnu.org
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lilypond-user digest..."
> Today's Topics:
> 1. Re: Feedback wanted: syntax highlighting in the LilyPond
> documentation (Wols Li
On 02/01/2022 16:32, Jean Abou Samra wrote:
I am colorblind (which BTW means that it's hard to distinguish certain
colors, not that everything is gray).
Sorry if I gave a wrong impression. I didn't
mean that everything actually looked gray, just
that it was the extreme imaginary case
Le 02/01/2022 à 17:01, Knute Snortum a écrit :
On Sun, Jan 2, 2022 at 7:10 AM Jean Abou Samra wrote:
...
[Marc]
It will be necessary to keep an uncolored version for men (in
principle women do not have this problem) who do not see well certain
colors.
This is taken care of -- the colors
On 02/01/2022 09:34, Marc Lanoiselée via LilyPond user discussion wrote:
It will be necessary to keep an uncolored version for men (in principle
women do not have this problem) who do not see well certain colors.
In principle (and practice) women DO suffer this problem. It's caused by
a
On Sun, Jan 2, 2022 at 7:10 AM Jean Abou Samra wrote:
>
...
> [Marc]
> > It will be necessary to keep an uncolored version for men (in
> > principle women do not have this problem) who do not see well certain
> > colors.
>
>
> This is taken care of -- the colors have been
> chosen to have enough
Le 02/01/2022 à 10:16, Valentin Petzel a écrit :
Hello Jean,
What I’ve done here is:
1) Make any macro that has a structural character bold. This helps in quickly
understanding the basic structure of the document. \tuplet is just a simple
music function with no real structural importance, so
Hi Jean,
I like the idea that it should be possible.
I would like for it to be (easily) customisable.
I already have a text editor colour scheme that I use for music, for
parts and scores I have found it is not so important.
My perspective is that I only need colour for highlighting key
Le 02/01/2022 à 05:52, Jean Abou Samra a écrit :
Le 02/01/2022 à 01:06, David Kastrup a écrit :
Jean Abou Samra writes:
Hi all,
There is an ongoing proposal to add syntax highlighting
in LilyPond's documentation. Since it is a notable change
to the documentation reading experience, user
Here are the appended images. That’s the problem if you quickly send the mail
because you need to do something.
Cheers,
Valentin
signature.asc
Description: This is a digitally signed message part.
Hello Jean,
What I’ve done here is:
1) Make any macro that has a structural character bold. This helps in quickly
understanding the basic structure of the document. \tuplet is just a simple
music function with no real structural importance, so it is not bold. Of
course it is arguable if
Le 02/01/2022 à 01:06, David Kastrup a écrit :
Jean Abou Samra writes:
Hi all,
There is an ongoing proposal to add syntax highlighting
in LilyPond's documentation. Since it is a notable change
to the documentation reading experience, user feedback would
be appreciated. You can browse a
Ransom
From: lilypond-user on behalf
of Valentin Petzel
Sent: Saturday, January 1, 2022 5:53 PM
To: Jean Abou Samra; lilypond-user@gnu.org
Cc: David Kastrup; Lilypond-User Mailing List
Subject: Re: Feedback wanted: syntax highlighting in the LilyPond
Jean Abou Samra writes:
> Hi all,
>
> There is an ongoing proposal to add syntax highlighting
> in LilyPond's documentation. Since it is a notable change
> to the documentation reading experience, user feedback would
> be appreciated. You can browse a syntax-highlighted version
> of the notation
Hi all,
There is an ongoing proposal to add syntax highlighting
in LilyPond's documentation. Since it is a notable change
to the documentation reading experience, user feedback would
be appreciated. You can browse a syntax-highlighted version
of the notation manual here:
43 matches
Mail list logo
