for i in *.ly; do lilycrop "$i"; done
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Re-bottom-of-EPS-output-cut-off-size-of-PDF-files-tp170572p170591.html
Sent from the User mailing list archive at Nabble.com.
__
shell wildcards, though.
Andrew
https://github.com/andrewacashner/lilypond/
>
> Message: 2
> Date: Thu, 15 Jan 2015 20:04:18 -0700 (MST)
> From: Jayaratna
> To: lilypond-user@gnu.org
> Subject: Re: Re:bottom of EPS output cut off (+ size of PDF files)
> Message-ID: <
/lilypond.1069038.n5.nabble.com/file/n170551/esempio3064-crop.pdf>
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Re-bottom-of-EPS-output-cut-off-size-of-PDF-files-tp170524p170551.html
Sent from the User mailing list archive a
message in context:
http://lilypond.1069038.n5.nabble.com/Re-bottom-of-EPS-output-cut-off-size-of-PDF-files-tp170524p170538.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.o
e at https://github.com/andrewacashner/lilypond/. Please
test and give feedback!
Thank you to Andrea for the original cropping process (you are
credited in the code).
Best,
Andrew
On Thu, Jan 15, 2015 at 2:42 AM, wrote:
>2. Re:bottom of EPS output cut off (+ size of PDF files) (Jaya
owing output:
originalpdf.pdf
originalpdf01.pdf
originalpdf02.pdf
originalpdf03.pdf
... etc.
Can I adapt this line:
pdftops -eps "$file".pdf
to manage the multiple single pages pdf?
Thank you,
Andrea
--
View this message in context:
http://lilypond.1069038.n5.nabble.com
Hi Andrew,
this Bash is going to be VERY(!!!) useful for me, thank you VERY(!!!)
much for posting it,
Andrea
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Re-bottom-of-EPS-output-cut-off-size-of-PDF-files-tp170186p170496.html
Sent from the User mailing list
I wrote earlier about the bug in which Lilypond with the eps backend
inaccurately calculates the bounding box, and Andrea provided a
working solution (thank you).
I turned it into this Bash script, which works well for me, though I
don't understand why this process should be necessary.
Intriguing
On 15.12.2014 14:21, Knut Petersen wrote:
Well, I did some very ugly things to a few postscript / low level scm files
this morning.
Nothing for release, only a proof of concept. These are the results from a
luatex test
page including four small lilypond snippets:
Update:
I generalized my tes
On Mon, 15 Dec 2014 20:33:57 +0600
Henning Hraban Ramm wrote:
> PS is much easier to write than PDF, since PS can be pure text, while PDF
> is always binary, even in „text“ form.
Technically, this is true. Experience has taught me that generating
PostScript via text fragments can easily lead to
Am 2014-12-15 um 17:35 schrieb Urs Liska :
>
> Am 15.12.2014 12:31, schrieb Werner LEMBERG:
>>> 1) Is it clear that nobody would need Postscript output itself,
>>>e.g. to produce something different than PDF?
>> PDF can be converted back to PS easily.
>>
>>> 2) Is that a feasible goal?
>> W
On 15.12.2014 11:05, Johan Vromans wrote:
On Mon, 15 Dec 2014 10:18:21 +0100
Knut Petersen wrote:
Shall we open a lilypond bug report? I don't know - the generated ps code
is valid and works, so there is no real bug. I think it would be a
feature request.
It's a bit of both. PostScript is muc
Am 15.12.2014 12:31, schrieb Werner LEMBERG:
1) Is it clear that nobody would need Postscript output itself,
e.g. to produce something different than PDF?
PDF can be converted back to PS easily.
2) Is that a feasible goal?
Well, it would be a good solution. However, we need a PDF creati
> 1) Is it clear that nobody would need Postscript output itself,
>e.g. to produce something different than PDF?
PDF can be converted back to PS easily.
> 2) Is that a feasible goal?
Well, it would be a good solution. However, we need a PDF creation
library, I guess...
Werner
___
Am 15. Dezember 2014 11:05:59 MEZ, schrieb Johan Vromans :
>On Mon, 15 Dec 2014 10:18:21 +0100
>Knut Petersen wrote:
>
>> Shall we open a lilypond bug report? I don't know - the generated ps
>code
>> is valid and works, so there is no real bug. I think it would be a
>> feature request.
>
>It's a
On Mon, 15 Dec 2014 10:18:21 +0100
Knut Petersen wrote:
> Shall we open a lilypond bug report? I don't know - the generated ps code
> is valid and works, so there is no real bug. I think it would be a
> feature request.
It's a bit of both. PostScript is much more optimized to deal with normal
's
I suggest you (because you know about that best) write a report to bug-lilypond.
I think this should be opened on our issue tracker,regardless labeling it bug
or enhancement.
Best
Urs
Am 15. Dezember 2014 10:18:21 MEZ, schrieb Knut Petersen
:
>
> you can't suppress subsetting for the Emmen
you can't suppress subsetting for the Emmentaler fonts. Can you send
a bug report to the gs people?
After a first look at the gs code I filed a bugreport:
http://bugs.ghostscript.com/show_bug.cgi?id=695728
And I think the comments to that are quite interesting. AFAICT (which isn't
very au
Am 12.12.2014 11:35, schrieb Knut Petersen:
On 08.12.2014 07:53, Knut Petersen wrote:
On 05.12.2014 20:51, Werner LEMBERG wrote:
Now I thought a bit and added "-dSubsetFonts=false" to the gs
parameter list in backend-library.scm. I also changed
lilyponddefs.ps to include white-on-white print
On 08.12.2014 07:53, Knut Petersen wrote:
On 05.12.2014 20:51, Werner LEMBERG wrote:
Now I thought a bit and added "-dSubsetFonts=false" to the gs
parameter list in backend-library.scm. I also changed
lilyponddefs.ps to include white-on-white print commands for all the
emmentaler glyphs used in
Am 08.12.2014 07:53, schrieb Knut Petersen:
Why does lilypond think it is a good idea to print a space at origin
using an otherwise unused font?
This is a very good question. IIRC, it comes from headers or footers
added by lilypond. It is obviously not possible to *completely*
disable that, h
On 05.12.2014 20:51, Werner LEMBERG wrote:
Now I thought a bit and added "-dSubsetFonts=false" to the gs
parameter list in backend-library.scm. I also changed
lilyponddefs.ps to include white-on-white print commands for all the
emmentaler glyphs used in the four examples (hint: grep, sed, sort &
> Now I thought a bit and added "-dSubsetFonts=false" to the gs
> parameter list in backend-library.scm. I also changed
> lilyponddefs.ps to include white-on-white print commands for all the
> emmentaler glyphs used in the four examples (hint: grep, sed, sort &
> uniq make it easy to get a list o
On 05.12.2014 00:25, Werner LEMBERG wrote:
How can I force lilypond to include the full emmentaler-design-size
font instead of only a subset?
LilyPond itself only produces PS files, *always* embedding complete
fonts, AFAIK. Thus ghostscript's `-dSubsetFonts=false' option should
work for Emmenta
> How can I force lilypond to include the full emmentaler-design-size
> font instead of only a subset?
LilyPond itself only produces PS files, *always* embedding complete
fonts, AFAIK. Thus ghostscript's `-dSubsetFonts=false' option should
work for Emmentaler also. Have you actually checked tha
Hi everybody!
When a lot of lilypond pdfs are included in a *TeX document,
a significant amount of the resulting pdf document is
wasted for differing subsets of fonts.
Identical subsets of fonts can be eliminated by ghostscript,
and ghostscript is also capable to construct an optimal subset
fro
On WinXP I have not experienced this. (However, only tried one file from
the 2.8 series - it is smaller now)
Bert
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
I just noticed that the stable 2.10 has been released, so I updated to
that. I was previously on 2.9.7 or something like that. I notice that
the PDF:s generated with 2.10 are about 25% larger that previously.
Not that it really matters, but I'm curious to what the cause might
be.
And, no, it has
28 matches
Mail list logo
