On Mon, Aug 30, 2021 at 10:49 AM Werner LEMBERG wrote:
> > The current SVG backend is glacially slow, and has suffered from
> > rendering discrepancies. I propose we retire it ASAP to be
> > replaced by Cairo.
>
> I don't use SVG normally, but this sounds like a good plan, especially
> beca
Le 05/09/2021 à 22:46, Jonas Hahnfeld via Discussions on LilyPond
development a écrit :
Hm, when Harm brought up this point in the previous thread in May, I
did not understand this to be a critical showstopper for adoption of
Guile 2.2 (is it?) or I would have prioritized this over working on the
Am Montag, dem 30.08.2021 um 20:01 +0200 schrieb Jean Abou Samra:
> > I would highly prefer to not mix switching the default backend with
> > switching to Guile 2.2 that will already be disruptive enough (yes,
> > it's going slower than I had hoped...).
>
>
> At the moment, I have trouble seeing
> I analyzed more closely in the issue
> https://gitlab.com/lilypond/lilypond/-/issues/6172
The garbling sample I have shown has two different issues.
#6172 is one of them.
I created #6173 for the other one.
https://gitlab.com/lilypond/lilypond/-/issues/6173
Le 03/09/2021 à 13:41, David Kastrup a écrit :
There is no point in dropping \postscript I would agree. There is a
point in changing example code that does not need it, though, in order
to make the code more generally useful, particularly since many examples
are copied by users and/or used as te
Most PDF readers have a mapping from Adobe-Japan1 CID to Unicode
code points as follows.
https://github.com/adobe-type-tools/mapping-resources-pdf/blob/master/pdf2unicode/Adobe-Japan1-UCS2
>>>
>>> Is it impossible to discover this mapping from the OTF file alone?
>>
>> If I understa
>>> Most PDF readers have a mapping from Adobe-Japan1 CID to Unicode
>>> code points as follows.
>>> https://github.com/adobe-type-tools/mapping-resources-pdf/blob/master/pdf2unicode/Adobe-Japan1-UCS2
>>
>> Is it impossible to discover this mapping from the OTF file alone?
>
> If I understand co
>> Most PDF readers have a mapping
>> from Adobe-Japan1 CID to Unicode code points as follows.
>> https://github.com/adobe-type-tools/mapping-resources-pdf/blob/master/pdf2unicode/Adobe-Japan1-UCS2
>
> Is it impossible to discover this mapping from the OTF file alone?
If I understand correctly, y
On Sat, Sep 4, 2021 at 1:14 PM Masamichi Hosoda wrote:
>
> > I analyzed more closely in the issue
> > https://gitlab.com/lilypond/lilypond/-/issues/6172
> >
> > Would you know how the mapping of character index => codepoint is
> > supposed to work for this font with character 3056 (辻) ?
>
> Most P
> I analyzed more closely in the issue
> https://gitlab.com/lilypond/lilypond/-/issues/6172
>
> Would you know how the mapping of character index => codepoint is
> supposed to work for this font with character 3056 (辻) ?
Most PDF readers have a mapping
from Adobe-Japan1 CID to Unicode code points
On Sat, Sep 4, 2021 at 9:12 AM Han-Wen Nienhuys wrote:
> >find ~/.fonts -name "HaranoAjiMincho-*.otf"
>
> I cloned https://github.com/trueroad/HaranoAjiFontsCN
>
> I didn´t reallize you had many repos named HaranoAjiFontsSomething. I
> installed the right ones, and can reproduce the problem.
>
>
On Sat, Sep 4, 2021 at 1:41 AM Masamichi Hosoda wrote:
>
> > I installed your Harano fonts in ~/.fonts. Fontconfig sees them, but I
> > still get DroidSans when I compile the snippet. How do I reproduce the
> > problem?
>
> Would you show me the results of the follwing commands?
>
> ```
> find ~/.
> I installed your Harano fonts in ~/.fonts. Fontconfig sees them, but I
> still get DroidSans when I compile the snippet. How do I reproduce the
> problem?
Would you show me the results of the follwing commands?
```
find ~/.fonts -name "HaranoAjiMincho-*.otf"
fc-list "HaranoAjiMincho"
lilypond -
On Fri, Sep 3, 2021 at 12:54 PM Masamichi Hosoda wrote:
> \version "2.22.0"
> \markup {
> \override #'(font-name . "HaranoAjiMincho")
> { 初見はハ長調で高音の白玉があった } }
> \markup {
> \override #'(font-name . "HaranoAjiMincho")
> \override #'(font-features . ("jp90"))
> { 辻井 逗子 飴玉 } }
> ```
I ins
Thomas Morley writes:
> Hi,
>
> some thoughts:
>
> A file like the attachment to
> http://lists.gnu.org/archive/html/lilypond-user/2013-11/msg00757.html
> would be a bit more work to convert, I suppose, although I didn't try ...
>
> ps-code not causing skylines, etc may be a feature in some cases
works great
thank you
Am 01.09.2021 um 16:24 schrieb Jean Abou Samra:
Le 01/09/2021 à 15:11, Rene Brandenburger a écrit :
I use the \postscript a lot when typesetting contemporary music e.g.
like this:
\version "2.20.0"
wave_line = \markup {
\with-dimensions #'(0 . 0) #'(0 . 0)
\postsc
> * when could/would we drop the PS backend altogether?
In my humble opinion,
the PS backend is still needed for CJK character handling.
When you copy and paste text from a PDF generated by the cairo backend,
some CJK characters are garbled.
By the PS backend, no such garbling occurs.
Here's a sa
On Fri, Sep 3, 2021 at 11:22 AM Richard Shann wrote:
> > Thank you! Previously I just hard-coded values for A4 paper but I
> > would
> > like to do it properly this time. I notice (peeking in scm/paper.scm)
> > that there is a Scheme symbol staff-space that holds this value, but
> > I
> > don't s
Am Fr., 3. Sept. 2021 um 11:32 Uhr schrieb Thomas Morley
:
> A file like the attachment to
> http://lists.gnu.org/archive/html/lilypond-user/2013-11/msg00757.html
> would be a bit more work to convert, I suppose, although I didn't try ...
>
The link to the attachment of above link is dead, thus I
Am Mi., 1. Sept. 2021 um 16:25 Uhr schrieb Jean Abou Samra :
>
> Le 01/09/2021 à 15:11, Rene Brandenburger a écrit :
> > I use the \postscript a lot when typesetting contemporary music e.g.
> > like this:
> >
> > \version "2.20.0"
> >
> >
> > wave_line = \markup {
> > \with-dimensions #'(0 . 0) #
On Fri, 2021-09-03 at 09:15 +0100, Richard Shann wrote:
> On Thu, 2021-09-02 at 20:19 +0200, Han-Wen Nienhuys wrote:
> > On Thu, Sep 2, 2021 at 4:32 PM Richard Shann > om
> > > wrote:
>
> [...]
> > > I
> > > presume the \path command is speaking in staff spaces while the
> > > border
> > > box ne
On Thu, 2021-09-02 at 20:19 +0200, Han-Wen Nienhuys wrote:
> On Thu, Sep 2, 2021 at 4:32 PM Richard Shann > wrote:
>
[...]
> > I
> > presume the \path command is speaking in staff spaces while the
> > border
> > box needs to be drawn within the edges of the page ...
>
> The standard staff size i
On Thu, 2021-09-02 at 19:33 +0100, Kevin Barry wrote:
> > This use case continues to be supported with
> > Cairo. Just convert \postscript to \path, wich
> > works both in the current PS backend and with Cairo.
>
> Is this something that can be done automatically with convert-ly?
No, the suggesti
On Thu, Sep 2, 2021 at 8:33 PM Kevin Barry wrote:
>
> > This use case continues to be supported with
> > Cairo. Just convert \postscript to \path, wich
> > works both in the current PS backend and with Cairo.
>
> Is this something that can be done automatically with convert-ly? If
> not then does
> This use case continues to be supported with
> Cairo. Just convert \postscript to \path, wich
> works both in the current PS backend and with Cairo.
Is this something that can be done automatically with convert-ly? If
not then does it justify a major version bump?
Kevin
On Thu, Sep 2, 2021 at 4:32 PM Richard Shann wrote:
> Thank you! I've managed to get this working, except that the border
> drawn runs off the page at right and bottom. I'm now faced with the
> challenge of finding out what the page size is in staff spaces - as I
> presume the \path command is sp
On Wed, 2021-09-01 at 17:47 +0200, Jean Abou Samra wrote:
> Le 01/09/2021 à 17:22, Richard Shann a écrit :
> > > > Denemo uses postscript to generate a title page with a border.
> > >
> > > From a glance at the output of
> > >
> > > git grep "postscript"
> > >
> > > in the Denemo repositor
Le 01/09/2021 à 17:22, Richard Shann a écrit :
Denemo uses postscript to generate a title page with a border.
From a glance at the output of
git grep "postscript"
in the Denemo repository, that should be easy to convert
to \path as above.
it was this paper block I had in mind specifical
On Wed, 2021-09-01 at 16:24 +0200, Jean Abou Samra wrote:
> Le 01/09/2021 à 15:11, Rene Brandenburger a écrit :
> > I use the \postscript a lot when typesetting contemporary music
> > e.g.
> > like this:
> >
> > \version "2.20.0"
> >
> >
> > wave_line = \markup {
> > \with-dimensions #'(0 . 0
Le 01/09/2021 à 15:11, Rene Brandenburger a écrit :
I use the \postscript a lot when typesetting contemporary music e.g.
like this:
\version "2.20.0"
wave_line = \markup {
\with-dimensions #'(0 . 0) #'(0 . 0)
\postscript #"0.3 setlinewidth 1 setlinecap [0 1]
0 0 0 setrgbcolor 0.00 -3.50
On Wed, 2021-09-01 at 15:11 +0200, Rene Brandenburger wrote:
> I use the \postscript a lot
Denemo uses postscript to generate a title page with a border.
Richard Shann
> when typesetting contemporary music e.g.
> like this:
>
> \version "2.20.0"
>
>
> wave_line = \markup {
> \with-dimens
I use the \postscript a lot when typesetting contemporary music e.g.
like this:
\version "2.20.0"
wave_line = \markup {
\with-dimensions #'(0 . 0) #'(0 . 0)
\postscript #"0.3 setlinewidth 1 setlinecap [0 1]
0 0 0 setrgbcolor 0.00 -3.50 moveto
0.23 -3.71 0.47 -3.93 1.00 -4.00 curveto
Am Dienstag, dem 31.08.2021 um 17:24 +0200 schrieb Jean Abou Samra:
> To me, the top priority would be getting the fresh
> Cairo backend to be tested as widely as possible, as
> soon as possible. Unfortunately, I currently have some
> doubt that releases with Cairo being opt-in will best
> achieve
Am Dienstag, dem 31.08.2021 um 11:34 +0200 schrieb Han-Wen Nienhuys:
> > Giving timing for a single HTML file is a bit dubious because it
> > requires processing all .tely files for cross-references. For the
> > influence of Cairo, you really want to compare the time it takes to run
> > lilypond-bo
Le 31/08/2021 à 14:47, Werner LEMBERG a écrit :
From my current understanding of missing features, the amount of
testing the backend can have received (or rather cannot, due to
novelty), and the nature of bugs that are found (both in Cairo
itself and the integration in LilyPond), I don't think t
> I'll look into PDF processing software. AFAICT, the subsetting
> retains the character mapping of the original font, so I think it
> should be possible to rewrite it to embed the Emmentaler font once,
> point all font references to the full font, and elide all the
> subsetted versions.
Thanks
Le 31/08/2021 à 12:37, Kevin Barry a écrit :
I would also have been inclined to say this suggests a major version
bump. But if what you say is true - that input is completely unchanged
- then it may not be necessary. Will the loss of the ps-command affect
users?
Basically, the \postscript mark
These changes/improvements are exciting. Thank you and Knut for the hard work!
> > I would say that this step requires going to LilyPond 3.0, along with
> > removing all the features and commands that cannot be implemented in
> > the Cairo backend, or that we don't want to.
>
> We can discuss this
On Mon, Aug 30, 2021 at 6:31 PM Jonas Hahnfeld wrote:
>
> Am Montag, dem 30.08.2021 um 10:16 +0200 schrieb Han-Wen Nienhuys:
> > With MR 897, I have been able to run the doc build through
> > Cairo. Results are very encouraging: the build is faster, while the
> > resulting PDF file is smaller.
>
>
Jonas Hahnfeld writes:
> Am Montag, dem 30.08.2021 um 18:47 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld via Discussions on LilyPond development
>> writes:
>>
>> > Giving timing for a single HTML file is a bit dubious because it
>> > requires processing all .tely files for cross-references. F
Am Montag, dem 30.08.2021 um 18:47 +0200 schrieb David Kastrup:
> Jonas Hahnfeld via Discussions on LilyPond development
> writes:
>
> > Giving timing for a single HTML file is a bit dubious because it
> > requires processing all .tely files for cross-references. For the
> > influence of Cairo, y
On Tue, Aug 31, 2021 at 7:13 AM Jan Nieuwenhuizen wrote:
>
> Han-Wen Nienhuys writes:
>
> Hi,
>
> > Also: apologies to reviewers for the large Merge-Request.
> > Unfortunately, the backend code was quite convoluted, and I didn't see
> > a way except to just slash my way through it. refactoring alo
Han-Wen Nienhuys writes:
Hi,
> Also: apologies to reviewers for the large Merge-Request.
> Unfortunately, the backend code was quite convoluted, and I didn't see
> a way except to just slash my way through it. refactoring along the
> way.
Sounds good, can I have a look at the patch set, do you h
> I would highly prefer to not mix switching the default backend with switching
> to Guile 2.2 that
> will already be disruptive enough (yes, it's going slower than I had
> hoped...).
At the moment, I have trouble seeing how Guile 2 could be made to work well.
The absence of error locations i
Jonas Hahnfeld via Discussions on LilyPond development
writes:
> Giving timing for a single HTML file is a bit dubious because it
> requires processing all .tely files for cross-references. For the
> influence of Cairo, you really want to compare the time it takes to
> run lilypond-book to get a
Am Montag, dem 30.08.2021 um 10:16 +0200 schrieb Han-Wen Nienhuys:
> With MR 897, I have been able to run the doc build through
> Cairo. Results are very encouraging: the build is faster, while the
> resulting PDF file is smaller.
As Werner remarked, only due to not using extractpdfmark.
> Also,
> Le 30 août 2021 à 10:16, Han-Wen Nienhuys a écrit :
>
> With MR 897, I have been able to run the doc build through
> Cairo. Results are very encouraging: the build is faster, while the
> resulting PDF file is smaller. Also, I think we could skip emitting
> EPS files for Cairo altogether, whi
> With MR 897, I have been able to run the doc build through Cairo.
> Results are very encouraging: the build is faster, while the
> resulting PDF file is smaller.
Great!
> -rw-r--r--. 1 hanwen hanwen 13M Aug 30 08:45 out-www-cairo/en/notation.pdf
This is still far too large IMHO. On my GNU/L
+jan for real now.
Also: apologies to reviewers for the large Merge-Request.
Unfortunately, the backend code was quite convoluted, and I didn't see
a way except to just slash my way through it. refactoring along the
way.
On Mon, Aug 30, 2021 at 10:16 AM Han-Wen Nienhuys wrote:
>
> With MR 897, I
With MR 897, I have been able to run the doc build through
Cairo. Results are very encouraging: the build is faster, while the
resulting PDF file is smaller. Also, I think we could skip emitting
EPS files for Cairo altogether, which would be another small speedup.
In timings below, I started with
50 matches
Mail list logo
