Re: [Issue #3947] fixing \huge et al.

[Kieren MacMillan]

Hi James,

> I am sure you know the process

Actually, I *don't*. This will be my first patch.

> make sure that there is a tracker issue



> AND that the tracker issue is marked as 'started'

'Accepted'. Is that better? Or at least sufficient?

> with patch 'new'

null

> git-cl should do this automatically.

I'll check again after I've done something git-y.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: [Issue #3947] fixing \huge et al.

[James]

Kieren,

On Sun, 25 Jun 2017 11:35:37 -0400
Kieren MacMillan  wrote:

> Hi Marc,
> 
> Thanks for the quick response.
> 
> > I think that no response means "yes, submit a patch" in this case.
> > If you checked your changes and did not find any negative effects,
> > then submitting a patch is the best way to go IMHO.  
> 
> Okay.
> 
> > The guidance/mentoring is great in principle, but it is way easier
> > for developers to comment on "official" patches during the review
> > process.  
> 
> Fair enough.
> I'll move forward towards a patch, and ping the list if I git-stumble.
> 
> Thanks,
> Kieren.

I am sure you know the process, but in case, just make sure that there
is a tracker issue AND that the tracker issue is marked as 'started'
with patch 'new' so that it appears on the countdown list for me to
check/test/move etc.

git-cl should do this automatically.

James

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

Re: [Issue #3947] fixing \huge et al.

[Kieren MacMillan]

Hi Marc,

Thanks for the quick response.

> I think that no response means "yes, submit a patch" in this case.
> If you checked your changes and did not find any negative effects,
> then submitting a patch is the best way to go IMHO.

Okay.

> The guidance/mentoring is great in principle, but it is way easier for 
> developers to comment on "official" patches during the review process.

Fair enough.
I'll move forward towards a patch, and ping the list if I git-stumble.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: [Issue #3947] fixing \huge et al.

[Marc Hohl]

Hi Kieren,

Am 25.06.2017 um 17:11 schrieb Kieren MacMillan:

Hi,

Another ten days has passed…

I guess I don't understand how the Lilypond development process 
works. I keep hearing we need people to jump in and learn how to 
develop/improve Lilypond. I took the initiative, found an issue I 
thought I could tackle, and offered a solution that appears to work 
with no unintended side-effects. I've now asked twice whether I 
should move towards a submittable patch, but have received no 
response in several weeks.



I think that no response means "yes, submit a patch" in this case.
If you checked your changes and did not find any negative effects,
then submitting a patch is the best way to go IMHO.

I will almost certainly require some hand-holding through the git 
process (n.b. I've already got LilyDev set up and running on my 
machine), which is one of the reasons I chose such a small bug as my 
first project. I guess I'll just push forward and try to get a patch 
submitted on my own, and come back to the list with any obstacles I 
hit during the git-ting process.


+1

I realize everybody's doing all of this essentially in their spare 
time… but perhaps there's a way that people like me — who are trying 
to get themselves up to speed so that they can contribute more on

the development side — could be guided/mentored a little more?
Otherwise it's a little discouraging, and thus probably not the
*best* plan towards increasing the developer pool.


Probably.

I imagine that your question slipped through ... there are only a few
active developers at the moment and some (partly emotional) discussions
that may cause other mails on the list to be forgotten/neglected.

I haven't committed anything for quite a while, but starting with a
small patch to get a grip on the git stuff and Patchy is probably the
best way to go. Writing patches can be frustrating sometimes, but nobody
in the list wants to discourage anybody.

The guidance/mentoring is great in principle, but it is way easier for 
developers to comment on "official" patches during the review process.


Cheers,
Marc

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

Re: [Issue #3947] fixing \huge et al.

[Kieren MacMillan]

Hi,

Another ten days has passed…

I guess I don't understand how the Lilypond development process works. I keep 
hearing we need people to jump in and learn how to develop/improve Lilypond. I 
took the initiative, found an issue I thought I could tackle, and offered a 
solution that appears to work with no unintended side-effects. I've now asked 
twice whether I should move towards a submittable patch, but have received no 
response in several weeks.

I will almost certainly require some hand-holding through the git process (n.b. 
I've already got LilyDev set up and running on my machine), which is one of the 
reasons I chose such a small bug as my first project. I guess I'll just push 
forward and try to get a patch submitted on my own, and come back to the list 
with any obstacles I hit during the git-ting process.

I realize everybody's doing all of this essentially in their spare time… but 
perhaps there's a way that people like me — who are trying to get themselves up 
to speed so that they can contribute more on the development side — could be 
guided/mentored a little more? Otherwise it's a little discouraging, and thus 
probably not the *best* plan towards increasing the developer pool.

Thanks,
Kieren.

> Hello,
> 
> Just checking on this, since a week has passed since I asked…
> Should I start moving towards a submittable patch?
> 
> Thanks,
> Kieren.
> 
>> Hi David,
>> 
>>> Maybe check the effects that super- and subscripts cause on a block of text?
>> 
>> Good thought. Doesn't seem to have a negative effect.
>> 
>> Other thoughts?
>> Or should I start moving towards a submittable patch?


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: GUB Ghostscript 9.21

[Masamichi Hosoda]

>> Phil Holmes:
>> ...
>>> /usr/bin/ld: cannot find -lfreetype
>> ...
>> ld cannot find libfreetype.so
>> Do you have it installed ?
>> Try this:
>> $ locate libfreetype.so
>> ...
>> /usr/lib/i386-linux-gnu/libfreetype.so
>> /usr/lib/i386-linux-gnu/libfreetype.so.6
>> /usr/lib/i386-linux-gnu/libfreetype.so.6.8.1
>> ...
>> 
> 
> I get:
> 
> /home/gub/NewGub/gub/target/freebsd-64/root/usr/lib/libfreetype.so
> /home/gub/NewGub/gub/target/freebsd-64/root/usr/lib/libfreetype.so.18
> /home/gub/NewGub/gub/target/freebsd-x86/root/usr/lib/libfreetype.so
> /home/gub/NewGub/gub/target/freebsd-x86/root/usr/lib/libfreetype.so.18
> /home/gub/NewGub/gub/target/linux-64/root/usr/lib/libfreetype.so
> /home/gub/NewGub/gub/target/linux-64/root/usr/lib/libfreetype.so.6
> /home/gub/NewGub/gub/target/linux-64/root/usr/lib/libfreetype.so.6.12.5
> /home/gub/NewGub/gub/target/linux-ppc/root/usr/lib/libfreetype.so
> /home/gub/NewGub/gub/target/linux-ppc/root/usr/lib/libfreetype.so.6
> /home/gub/NewGub/gub/target/linux-ppc/root/usr/lib/libfreetype.so.6.12.5
> /home/gub/NewGub/gub/target/linux-x86/root/usr/lib/libfreetype.so
> /home/gub/NewGub/gub/target/linux-x86/root/usr/lib/libfreetype.so.6
> /home/gub/NewGub/gub/target/linux-x86/root/usr/lib/libfreetype.so.6.12.5
> /home/gub/NewGub/gub/target/tools/root/usr/lib/libfreetype.so
> /home/gub/NewGub/gub/target/tools/root/usr/lib/libfreetype.so.6
> /home/gub/NewGub/gub/target/tools/root/usr/lib/libfreetype.so.6.12.5
> /usr/lib/i386-linux-gnu/libfreetype.so.6
> /usr/lib/i386-linux-gnu/libfreetype.so.6.11.1

If I understand correctly,
your system is Ubuntu 14.04 LTS 32 bit (i386-linux-gnu).
It seems that your system missing this file:
/usr/lib/i386-linux-gnu/libfreetype.so

So `ld` cannot find `-lfreetype`.

My system (Ubuntu 14.04 LTS 64 bit, x86_64-linux-gnu) has this file:
/usr/lib/x86_64-linux-gnu/libfreetype.so

So `ld` can find `-lfreetype`.
There is no problem.

I cannot reproduce the issue. However, I've created a patch.
Would you try it?
https://github.com/gperciva/gub/pull/40

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

Re: Using/requiring Cairo

[David Kastrup]

k...@aspodata.se writes:

> David Kastrup:
> ...
>> I don't see myself able to deal with all potential icky graphics code
>> in LilyPond, and I don't see anybody else stepping up either.
> ...
>
> Just for the record, I'm interested in icky graphics code.

There is no shortage in LilyPond and I haven't seen anybody stepping up.

-- 
David Kastrup

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

Re: Using/requiring Cairo

[Han-Wen Nienhuys]

On Sun, Jun 25, 2017 at 2:05 PM, David Kastrup  wrote:

>> I would be much more supportive if you could show some numbers where
>> memory/CPU is used right now, and could show some data how much Cairo
>> would improve on things. It's quite possible that you are right, but
>> then it should be easy to come up with some supporting data.
>
> I'm at a loss here how to arrive at such data without doing the actual
> work.

Since the final page is a big stencil, I think you should be able to
count how much memory it consumes in cells and string literals. That
gives some ballpark estimate of how memory intensive the backend is.
Since grob typically constructs one stencil, I would be surprised that
the stencil machinery would use more memory than the whole property
list machinery (and hence: that it would make a big dent in memory
usage), but that's your gut feeling against mine, which is what I want
to get away from.

> What isn't clear to me is how the font integration into Cairo surfaces
> is going to work.  I guess that this will be the main problem for making
> Cairo actually be responsible for producing output rather than serving
> "merely" as an internal graphics toolkit.
>
> --
> David Kastrup



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

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

Re: Using/requiring Cairo

[karl]

David Kastrup:
...
> I don't see myself able to deal with all potential icky graphics code in
> LilyPond, and I don't see anybody else stepping up either.
...

Just for the record, I'm interested in icky graphics code.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57



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

Re: Using/requiring Cairo

[karl]

David Kastrup:
...
> Han-Wen Nienhuys  writes:
...
> > I would be much more supportive if you could show some numbers where
> > memory/CPU is used right now, and could show some data how much Cairo
> > would improve on things. It's quite possible that you are right, but
> > then it should be easy to come up with some supporting data.
> 
> I'm at a loss here how to arrive at such data without doing the actual
> work.
...

There is a project that did a similar switch in nov. 2013, and they
use c + guile, so there are some similarities:

http://git.geda-project.org/geda-gaf/
in commit be4ed1c509e9cd808222f7e32e6ee2e602f58662

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57



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

Re: Using/requiring Cairo

[David Kastrup]

Just responding to a minor point:

Han-Wen Nienhuys  writes:

> I suppose that functions like
>
>   https://www.cairographics.org/manual/cairo-Paths.html#cairo-path-extents
>
> would be a boon.
>
> I was tickled to reply to your mail, because it was full of complaints
> ('hugely inefficient', 'humongous amount of resources'), without any
> measurements. Optimizing code without measuring is common pitfall, and
> I would not want you to fall in it.

I'm not really talking about "optimizing" here rather than "sanitizing"
or even better "throwing away".  I am aware that not all of Cairo is
what I would consider polished, but given the comparative manpower
interested in LilyPond and Cairo, I think it would leave us with less
trouble at our own doorstep if we can move to identifying problems with
Cairo rather than with LilyPond.

I don't see myself able to deal with all potential icky graphics code in
LilyPond, and I don't see anybody else stepping up either.  Shifting
some of the problems to Cairo is partly a copout, but partly it also
obliterates making decisions for how to deal with all the data shuffling
we are now doing: instead of reinventing what Cairo does with regard to
its representations, stealing them might save us additional work further
down the road.

> I would be much more supportive if you could show some numbers where
> memory/CPU is used right now, and could show some data how much Cairo
> would improve on things. It's quite possible that you are right, but
> then it should be easy to come up with some supporting data.

I'm at a loss here how to arrive at such data without doing the actual
work.

What isn't clear to me is how the font integration into Cairo surfaces
is going to work.  I guess that this will be the main problem for making
Cairo actually be responsible for producing output rather than serving
"merely" as an internal graphics toolkit.

-- 
David Kastrup

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

Re: Using/requiring Cairo

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Sat, Jun 24, 2017 at 5:54 PM, David Kastrup  wrote:
>> Han-Wen Nienhuys  writes:
>>
>>> On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup  wrote:

 The first step would likely just involve moving to Cairo data
 structures while keeping most of the current code except where the
 code would duplicate Cairo API calls in a reasonably
 straightforward way.
>>>
>>> I would suggest trying make a GUILE binding of sorts for Cairo,
>>> adding that in parallel to existing GS support, and hacking untili
>>> you have feature parity. Then drop the GS support, and migrate the
>>> cairo data structures more towards the core of the program as
>>> needed.
>>
>> The cost of the Cairo dependency is significant, so it would
>> certainly help if the payback was significant as well.
>
> Another approach could be to integrate it, and use it to replace all
> bounding box computations, but continue to use Scheme expression =>
> string => PS => PDF approach for the evaluation. That would let you
> get rid of some of the crummy code you quoted.

That's the "The first step" bit above, though "Scheme expression" would
likely not be a naked list but a smob containing a Cairo data structure
at its core.  But the output generation would be mostly the same.

But that's not the ultimate end state of course since it makes
generating output via Cairo comparatively low-hanging fruit (mostly
meaning that we have to get the font handling right).

Of course, we want to avoid packing and unpacking Cairo data structures
all the time as well: the basic processing flow should try to stick to
working with one representation.

> In addition, you could create a cross-test mode, where you compare the
> Cairo bounding boxes with the traditional ones, to find bugs.

When the internal data structures change, keeping the previous code
operative might be a whole lot of pain.  I suspect that comparing
results of different compilations/branches might be more feasible even
if the comparison gets less detailed.  But at least memory/performance
comparisons would likely be more representative.

-- 
David Kastrup

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

Re: GUB Ghostscript 9.21

[Phil Holmes]

- Original Message - 
From: 

To: 
Sent: Sunday, June 25, 2017 12:13 PM
Subject: Re: GUB Ghostscript 9.21



Phil Holmes:
...

/usr/bin/ld: cannot find -lfreetype

...

ld cannot find libfreetype.so

Do you have it installed ?
Try this:

$ locate libfreetype.so
...
/usr/lib/i386-linux-gnu/libfreetype.so
/usr/lib/i386-linux-gnu/libfreetype.so.6
/usr/lib/i386-linux-gnu/libfreetype.so.6.8.1
...



I get:

/home/gub/NewGub/gub/target/freebsd-64/root/usr/lib/libfreetype.so
/home/gub/NewGub/gub/target/freebsd-64/root/usr/lib/libfreetype.so.18
/home/gub/NewGub/gub/target/freebsd-x86/root/usr/lib/libfreetype.so
/home/gub/NewGub/gub/target/freebsd-x86/root/usr/lib/libfreetype.so.18
/home/gub/NewGub/gub/target/linux-64/root/usr/lib/libfreetype.so
/home/gub/NewGub/gub/target/linux-64/root/usr/lib/libfreetype.so.6
/home/gub/NewGub/gub/target/linux-64/root/usr/lib/libfreetype.so.6.12.5
/home/gub/NewGub/gub/target/linux-ppc/root/usr/lib/libfreetype.so
/home/gub/NewGub/gub/target/linux-ppc/root/usr/lib/libfreetype.so.6
/home/gub/NewGub/gub/target/linux-ppc/root/usr/lib/libfreetype.so.6.12.5
/home/gub/NewGub/gub/target/linux-x86/root/usr/lib/libfreetype.so
/home/gub/NewGub/gub/target/linux-x86/root/usr/lib/libfreetype.so.6
/home/gub/NewGub/gub/target/linux-x86/root/usr/lib/libfreetype.so.6.12.5
/home/gub/NewGub/gub/target/tools/root/usr/lib/libfreetype.so
/home/gub/NewGub/gub/target/tools/root/usr/lib/libfreetype.so.6
/home/gub/NewGub/gub/target/tools/root/usr/lib/libfreetype.so.6.12.5
/usr/lib/i386-linux-gnu/libfreetype.so.6
/usr/lib/i386-linux-gnu/libfreetype.so.6.11.1




--
Phil Holmes

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

Re: Using/requiring Cairo

[Han-Wen Nienhuys]

On Sat, Jun 24, 2017 at 5:54 PM, David Kastrup  wrote:
> Han-Wen Nienhuys  writes:
>
>> On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup  wrote:
>>> What does that mean?  Mainly a viable migration strategy where we might
>>> be able to drop catering for a whole lot of graphics programming
>>> ourselves by introducing a dependency on Cairo.  I am not overly
>>
>> what "catering for graphic programming" mean? There is graphical
>> programming, but a lot of it is done already. Moving towards a new
>> library will be a big undertaking, so it could use more justification.
>>
>>> enthused about the programming quality of Cairo but LilyPond's quality
>>> tends to be worse in the same departments
>>
>> gee, thanks.
>
> Shrug.  What do you expect of large amount of code that's written once
> and basically left alone afterwards?  The SVG backend produces sort-of
> experimental code (and still has font/spacing problems that "should not
> be there").  There are significant remaining parts of the internals that
> work with radians instead of degrees (like all graphics formats,
> libraries and backends use, including PostScript/PDF), leading to
> numerical pain because right angles have no numerically stable
> representation.
>
> Basically everything dealing with transformation matrices or
> coefficients unpacks Scheme lists (instead of uniform arrays or records
> matched to C data structures) into reals and back.
>
> There is, both in C as well as in Scheme, code like
>
> (define (make-bezier-sandwich-stencil coords thick)
>(make-path-stencil
>`(moveto
>,(car (list-ref coords 0))
>,(cdr (list-ref coords 0))
>  curveto
>,(car (list-ref coords 1))
>,(cdr (list-ref coords 1))
>,(car (list-ref coords 2))
>,(cdr (list-ref coords 2))
>,(car (list-ref coords 3))
>,(cdr (list-ref coords 3))
>  curveto
>,(car (list-ref coords 4))
>,(cdr (list-ref coords 4))
>,(car (list-ref coords 5))
>,(cdr (list-ref coords 5))
>,(car (list-ref coords 0))
>,(cdr (list-ref coords 0))
>  closepath)
>thick
>1
>1
>#t))
>
> that goes to a lot of effort to just juggle data from one Scheme
> representation into another Scheme representation, without an actual
> representation useful for efficient processing.
>
> There is code like
>
> (define (bezier-part-min-max x1 x2 x3 x4)
>   ((lambda (x) (list (reduce min 1 x) (reduce max -1 x)))
>(map
> (lambda (x)
>   (+ (* x1 (expt (- 1 x) 3))
>  (+ (* 3 (* x2 (* (expt (- 1 x) 2) x)))
> (+ (* 3 (* x3 (* (- 1 x) (expt x 2
>(* x4 (expt x 3))
> (if (< (+ (expt x2 2) (+ (expt x3 2) (* x1 x4)))
>(+ (* x1 x3) (+ (* x2 x4) (* x2 x3
> (list 0.0 1.0)
> (filter
>  (lambda (x) (and (>= x 0) (<= x 1)))
>  (append
>   (list 0.0 1.0)
>   (map (lambda (op)
>  (if (not (eqv? 0.0
> (exact->inexact (- (+ x1 (* 3 x3)) (+ x4 (* 3 
> x2))
>  ;; Zeros of the bezier curve
>  (/ (+ (- x1 (* 2 x2))
>(op x3
>(sqrt (- (+ (expt x2 2)
>(+ (expt x3 2) (* x1 x4)))
> (+ (* x1 x3)
>(+ (* x2 x4) (* x2 x3)))
> (- (+ x1 (* 3 x3)) (+ x4 (* 3 x2
>  ;; Apply L'hopital's rule to get the zeros if 0/0
>  (* (op 0 1)
> (/ (/ (- x4 x3) 2)
>(sqrt (- (+ (* x2 x2)
>(+ (* x3 x3) (* x1 x4)))
> (+ (* x1 x3)
>(+ (* x2 x4) (* x2 x3)
>(list + -
>
> which just is better done in C, and even better left in the
> responsibility of people who specialize in maintaining a graphics
> library rather than a music typesetting program.

Well, I stand corrected then.

> Stencils and their compositions are represented in Scheme data
> structures that take considerable time to traverse and interpret even
> though they aren't actually traversed and interpret in Scheme itself all
> that much.
>
> We've had reports where large works exhausted a 32bit address space.
>
> Cairo is just modeled around a different programming model and data
> structures suitable for the processing that its API provides.

I suppose that functions like

  https://www.cairographics.org/manual/cairo-Paths.html#cairo-path-extents

would be a boon.

I was tickled to reply to your mail, because it was full of complaints
('hugely inefficient', 'humongous amount of resources'), without any
measurements. Opti

Re: GUB Ghostscript 9.21

[karl]

Phil Holmes:
...
> /usr/bin/ld: cannot find -lfreetype
...

ld cannot find libfreetype.so

Do you have it installed ?
Try this:

$ locate libfreetype.so
...
/usr/lib/i386-linux-gnu/libfreetype.so
/usr/lib/i386-linux-gnu/libfreetype.so.6
/usr/lib/i386-linux-gnu/libfreetype.so.6.8.1
...

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57



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

Re: Using/requiring Cairo

[David Kastrup]

k...@aspodata.se writes:

> David
>> k...@aspodata.se writes:

> My point was:
>> > Though, my conclusion was that pdf is not better than ps regarding
>> > postprocessing, and yes I know that pdf (depending on pdf version) has
>> > some features that ps don't have.
>> 
>> But nobody is talking about PDF.
>
> You seem to have a short memory, from your initial message:
>   last time I looked at Cairo, its PDF generation was not really suitable
>   ...
>   We might also be able to forego creating PostScript as an intermediate
>   stage to creating PDF and create bitmap formats without using PostScript
>   as well (again, this should really speed up things).

So where do you read _anything_ concerning PDF that has _anything_ to do
with how LilyPond creates PostScript?  You changed the topic to
PostScript output, and PDF just does not factor into it.  Neither did
you state that you wanted to process LilyPond's PostScript output and
_then_ convert to a bitmap or PDF.

>> The difference in question is Cairo-generated PostScript vs the
>> PostScript generated by Scheme programming and LilyPond's
>> music-drawing-routines.ps and encodingdefs.ps .
>
> The Cairo-generated ps is much less readable than lilyponds.
>
> If you wanted to get rid of the lilyponds own generation of PS, I 
> offered my help to get it up to speed instead, but you didn't
> understand that since:
>
>> >> "taking care of PostScript" is not related to converting LilyPond's
>> >> graphics internals to Cairo since LilyPond's graphics internals are
>> >> not written in PostScript.
>
> You are obviously not understanding my offer and your mind is set on 
> using cairo instead.

I rather get the impression that you are not understanding your offer.

The architectural problems with LilyPond's graphics processing have
nothing to do with PostScript generation.  It would make sense to
delegate a lot of them to Cairo.  When doing that, there is no point in
_not_ using Cairo also for creating output, in particular since it will
provide a number of efficient well-supported targets without extra
effort and will write PDF and bitmap targets (and vector targets and X
and GL targets, very useful for integrated surfaces like Frescobaldi)
without needing to go through Ghostscript.

I don't expect that the Cairo backend for PostScript and even PDF will
start out competitive with what LilyPond has already: I expect a period
where it will be used in parallel with the existing backends, just like
the TeX backend existed for a while when LilyPond produced direct
PostScript output.

Now in particular font handling is a full-blown nuisance occupying
several LilyPond developers.  This will not likely change but move to
the Cairo backend since the payoff for that work is quite higher (for
example, we currently have defective font handling for the separate SVG
backend).  If you want to maintain a separate PostScript backend, this
will include maintaining its font handling.

Can you imagine how much work it would have been separately maintaining
a TeX backend instead of removing it from LilyPond all those years of
LilyPond 2?  Basically you are stating that you want to do exactly that
with the PostScript backend, and I am telling you that it will be more
work than you likely realize.

So you tell me I have no idea what I am talking about but don't bother
to point out _any_ particulars where you consider my analysis faulty.

-- 
David Kastrup

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

Re: GUB Ghostscript 9.21

[Phil Holmes]

When trying to build Gub today, I got the following error:

invoking cd /home/gub/NewGub/gub/target/tools/build/ghostscript-9.21 && make 
CC=cc CCAUX=cc C_INCLUDE_PATH= CFLAGS= CPPFLAGS= GCFLAGS= LIBRARY_PATH= 
obj/aux/genconf obj/aux/echogs obj/aux/genarch obj/arch.h
cc -O2 -I/home/gub/NewGub/gub/target/tools/src/ghostscript-9.21/base -o 
./obj/aux/genconf 
/home/gub/NewGub/gub/target/tools/src/ghostscript-9.21/base/genconf.c -lfreetype 
-lm -ldl -rdynamic

/usr/bin/ld: cannot find -lfreetype
collect2: error: ld returned 1 exit status
make: *** [obj/aux/genconf] Error 1
Command barfed: cd /home/gub/NewGub/gub/target/tools/build/ghostscript-9.21 
&& make CC=cc CCAUX=cc C_INCLUDE_PATH= CFLAGS= CPPFLAGS= GCFLAGS= 
LIBRARY_PATH= obj/aux/genconf obj/aux/echogs obj/aux/genarch obj/arch.h


Please advise.


--
Phil Holmes


- Original Message - 
From: "Masamichi Hosoda" 

To: 
Cc: 
Sent: Saturday, June 24, 2017 3:02 AM
Subject: GUB Ghostscript 9.21



Phil,

Would you merge this pr and try following command before next `make 
lilypond'?

https://github.com/gperciva/gub/pull/39

$ git fetch orign
$ git checkout master
$ git merge origin/master

Thanks.




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

Re: Using/requiring Cairo

[karl]

David
> k...@aspodata.se writes:
> > Werner:
...
> >> > And my interest was in reading pdf's, so I can write programs to
> >> > extract the info I want from pdf's.
> >> 
> >> Have you tried `pdftk' to uncompress a PDF file?  It's then almost as
> >> readable as a plain PS file (see attachments).
> >
> > No, it looks promising, thanks, now I have to find out how it does
> > that.

Found out that there is no public source:
 https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/
it is based in iText lib, which (or OpenPDF) I could use if I want to
use java.

I could possible use
 svn co http://svn.code.sf.net/p/podofo/code/podofo/trunk podofo
or try to desciffre libpoppler.

> Depending on what "Extract the info you want from PDFs" means, pdf2dsc
> can be quite handy.

Thanks, but it is not helping. I want to find lines and text in pdfs, 
to basically identify tables. Since pdf is not much more structered than
ps I have to use clever thinking. If you really want to help have a 
look at: http://aspodata.se/git/openhw/pdftosym/pdfextr.pl

My point was:
> > Though, my conclusion was that pdf is not better than ps regarding
> > postprocessing, and yes I know that pdf (depending on pdf version) has
> > some features that ps don't have.
> 
> But nobody is talking about PDF.

You seem to have a short memory, from your initial message:
  last time I looked at Cairo, its PDF generation was not really suitable
  ...
  We might also be able to forego creating PostScript as an intermediate
  stage to creating PDF and create bitmap formats without using PostScript
  as well (again, this should really speed up things).

> The difference in question is
> Cairo-generated PostScript vs the PostScript generated by Scheme
> programming and LilyPond's music-drawing-routines.ps and encodingdefs.ps
> .

The Cairo-generated ps is much less readable than lilyponds.

If you wanted to get rid of the lilyponds own generation of PS, I 
offered my help to get it up to speed instead, but you didn't
understand that since:

> >> "taking care of PostScript" is not related to converting LilyPond's
> >> graphics internals to Cairo since LilyPond's graphics internals are
> >> not written in PostScript.

You are obviously not understanding my offer and your mind is set on 
using cairo instead.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57



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

PATCHES - Countdown for June 25th

[James]

Hello,

Sorry for the delay between this and the previous countdown. I should
be back on normal schedule now.

Here is the current patch countdown list. The next countdown will be on
June 28th.

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/



Push:


5148 Various chain-assoc-get -> #:properties - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5148
http://codereview.appspot.com/323940043


Countdown: No patches on countdown at this time.


Review:


5150 Update Finnendahl testimony info - Urs Liska
https://sourceforge.net/p/testlilyissues/issues/5150
http://codereview.appspot.com/320690043


5149 lilypond-manuals.css: Add a maximum width for manuals sidebar -
Paul Morris https://sourceforge.net/p/testlilyissues/issues/5149
http://codereview.appspot.com/328740043


New: No New patches at this time.


Regards

James

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