Reduce size of *TeX generated pdfs with lilypond snippets

The attached patch (against 2.18.2) changes the way lilypond uses fonts to draw glyphs. It avoids to used glyphshow for all emmentaler glyphs and adds encoding vectors to the emmentaler fonts before they are used. It also changes the ghostscript parameters used to generate pdfs from postscript

Re: Reduce size of *TeX generated pdfs with lilypond snippets

On 29.12.2014 05:56, Werner LEMBERG wrote: Please report this to the author of pdfsizeopt.py, who is still maintaining the program (though not *very* active, it seems). I'll do that soon, but first I'll look at the code myself. - link targets in files processed by ghostscript git master are

Re: Reduce size of *TeX generated pdfs with lilypond snippets

On 29.12.2014 09:15, Werner LEMBERG wrote: If you find it straightforward to encapsulate the code, then we can probably incorporate it. Knut, are you willing to work on that, this is, adding a command line argument and properly documenting it? Yes, I could do that. cu, Knut

Re: Reduce size of *TeX generated pdfs with lilypond snippets

On 28.12.2014 23:46, Keith OHara wrote: if we can avoid whatever problems induced HanWen to move to using glyph names in the .ps. Well, using glyphshow and glyphnames was and is easy, and for a normal document it is a very efficient solution. cu, Knut

Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)

On 15.01.2015 17:01, d...@gnu.org wrote: PDFTeX apparently does merge subsetted fonts, Which version? so I don't think we should need to include the complete fonts in order to get font merging. But we probably should work with coding vectors so that we can use identical font names, just

Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)

On 15.01.2015 14:47, d...@gnu.org wrote: On 2015/01/15 13:18:46, Knut_Petersen_t-online.de wrote: On 15.01.2015 13:15, mailto:d...@gnu.org wrote: On 2015/01/15 12:01:55, Knut_Petersen_t-online.de wrote: Ghostscript does the font merging. Any idea whether something could be done to make

Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)

On 15.01.2015 10:45, d...@gnu.org wrote: Reliable? If I remember correctly, the tool used for combining the fonts (ppdfsizeopt.py) Ghostscript does the font merging. fails on the PDF files from PDFLaTeX, so there must be an additional iteration through GhostScript. This additional

Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)

On 15.01.2015 12:49, lemzw...@googlemail.com wrote: The hyperlink issue is not related to the --bigpdf option (since it is a bug in ghostscript), so I don't think that this is a showstopper. Well, it means that the code currently cannot be used to build lilyponds own documentation. cu, Knut

Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)

On 15.01.2015 13:15, d...@gnu.org wrote: On 2015/01/15 12:01:55, Knut_Petersen_t-online.de wrote: Ghostscript does the font merging. Any idea whether something could be done to make PDFTeX do the font merging instead when including all the PDF files? No, not really. That would require a

Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)

On 15.01.2015 13:12, d...@gnu.org wrote: If external hyperlinks from our documentation PDF to other files stop working, we cannot make this the default way of building our documentation. Indeed. Building lilypond with --bigpdfs enabled by default is a good test for that code, nothing more,

Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)

On 12.01.2015 06:56, lemzw...@googlemail.com wrote: https://codereview.appspot.com/194090043/diff/20001/Documentation/usage/running.itely File Documentation/usage/running.itely (right): https://codereview.appspot.com/194090043/diff/20001/Documentation/usage/running.itely#newcode187

Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)

On 14.01.2015 08:15, lemzw...@googlemail.com wrote: Hmm. I can't find in your description that `--bigpdfs' creates *big* output files that get later reduced to small one by running ghostscript again. https://codereview.appspot.com/194090043/ No? Have a look at the patch sent to

Re: [PATCH] Reduce size of *TeX generated pdfs, Version 2

On 09.01.2015 10:38, James Lowe wrote: On 08/01/15 19:10, Knut Petersen wrote: On 08.01.2015 19:10, James wrote: On 08/01/15 12:18, Knut Petersen wrote: So here is Version 2 I fixed a few issues with version 1, added a command line option --bigpdf / -b, and documented

Re: [PATCH] Reduce size of *TeX generated pdfs, Version 2

Hi James! Attached is a small *.tex document that can be translated by xelatex or lualatex, one page including four small snippets. It demonstrates that also small documents with only a few snippets benefit from the --bigpdf patch. lualatex must be called with the --shell-escape parameter to

[PATCH] Reduce size of *TeX generated pdfs, Version 2

: Knut Petersen knut_peter...@t-online.de Date: Thu, 8 Jan 2015 12:37:39 +0100 Subject: [PATCH] Implement a new command line option --bigpdf If given on the command line, --bigpdf or -b tell lilypond to produce pdfs optimized for TeX documents that include multiple lilypond pdfs Pdf documents

Re: [PATCH] Reduce size of *TeX generated pdfs, Version 2

On 08.01.2015 19:10, James wrote: On 08/01/15 12:18, Knut Petersen wrote: So here is Version 2 I fixed a few issues with version 1, added a command line option --bigpdf / -b, and documented that option in the german and english versions of usage.pdf . The patch is based

Re: 2.19.31 Notation Reference glitch

Am 27.12.2015 um 12:29 schrieb David Kastrup: I think the easier option would be to update our version of texinfo.tex again. The current version supports both characters. A full build with texinfo.tex version 2015-12-20.12 succeeded and cured the problem. cu, Knut

Issue 2314 - workaround and patch

ets are used by other programs. cu, Knut >From 02ea463357d23d3ff3eaa42e097be58dc7e62796 Mon Sep 17 00:00:00 2001 From: Knut Petersen <knut_peter...@t-online.de> Date: Mon, 21 Dec 2015 13:19:28 +0100 Subject: [PATCH] Dont emit \space glyph as empty page number Signed-off-by: Knut Peter

Re: making QUIET_BUILD the default

Am 29.12.2015 um 09:52 schrieb Werner LEMBERG: Is there a particular reason to no making `QUIET_BUILD' the default? For Metafont, it's extremely chatty otherwise... I prefer a verbose build and a script to save the chatty output to a logfile: #!/bin/bash RED='\033[0;31m' NOC='\033[0m'

Re: broken doc build (orchestra.ly)

"make doc" succeeds again, at least here. [newer versions]: make doc succeeds dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8: fixes "make doc" failure here 4b4a2cae9953cff69159f10763e990f5e4265ddd: lilypond does not build cccd7f9574c72ccecca00641d7a5ea3e8ce99cfd: still broken "make doc" [...]

Re: broken doc build (orchestra.ly)

Am 25.05.2016 um 16:14 schrieb David Kastrup: What about current master? More exactly, did 56a1519b44d1a0a8500c43236ae644053cc1f25b make a difference? No, both 56a1519b4 and a1467ba6de6 fail to process orchestra.ly. More tomorrow. Knut ___

Re: broken doc build (orchestra.ly)

Am 25.05.2016 um 15:58 schrieb Phil Holmes: Knut, did you use any options to ./configure ? config.log should mention how configure was called. I use the following script to build lilypond: RED='\033[0;31m' NOC='\033[0m' function doit { AT=`date +"%s"` echo -en exec $RED$1$NOC in `pwd`

Re: Still cannot make doc :(

Am 29.05.2016 um 13:52 schrieb David Kastrup: I have to see whether I have a chance to run a 64 bit kernel on my system: I used to for a few years (and consequently was able to look at 64 bit code), but the current laptop has an Nvidia card and Ubuntu's kernel/library setup did not manage to

Re: compiling lilypond fails

Am 24.06.2016 um 15:13 schrieb David Kastrup: At any rate, this implies that TRANSLATOR_INHERIT fails doing its job when it has to inherit overloaded template functions with a single "using" instruction. I propose the following patch (to current master). Does it change something for you? No:

Re: compiling lilypond fails

Am 24.06.2016 um 15:57 schrieb David Kastrup: Knut Petersen <knut_peter...@t-online.de> writes: Am 24.06.2016 um 15:13 schrieb David Kastrup: At any rate, this implies that TRANSLATOR_INHERIT fails doing its job when it has to inherit overloaded template functions with a single

Re: compiling lilypond fails

Building lilypond is also broken here: From build log == /home/knut/sources/lily/lily/slur-engraver.cc: In static member function 'static void Slur_engraver::boot()': /home/knut/sources/lily/lily/include/translator.icc:116:40: error: '_proto_engraver::listen_slur' is not a valid

Re: compiling lilypond fails

Am 24.06.2016 um 16:43 schrieb David Kastrup: Ok, next try. On top of HEAD: In file included from /home/knut/sources/lily/lily/slur-engraver.cc:32:0: /home/knut/sources/lily/lily/slur-engraver.cc: In static member function 'static void Slur_engraver::boot()':

Re: compiling lilypond fails

Am 25.06.2016 um 10:36 schrieb David Kastrup: Ok, issue 4903 is now in master. What's the news on make -k output now? Does applying the last patch (the one with ENGRAVER_INHERIT in its title) make any difference in the amount of reported errors? knut@golem:~/sources/lily> ../mklily Building

Re: text-replacements: add and the like (issue 281470043 by simon.albre...@mail.de)

How should I (and James) interpret the silence here? Any more opinions? It would also help ly2video users as that software requires pure 7-bit chars. Currently I use e.g. "\concat{ W \char ##x0fc nsche } }" instead of "Wünsche". cu, Knut ___

Re: broken doc build (orchestra.ly)

Am 20.05.2016 um 14:20 schrieb David Kastrup: Knut Petersen <knut_peter...@t-online.de> writes: Hi everybody! Building the current git lilypond binary succeeds, but building the documentation is broken even if I try a single core build. [...] So there really is a lot of "Huh

broken doc build (orchestra.ly)

Hi everybody! Building the current git lilypond binary succeeds, but building the documentation is broken even if I try a single core build. exec ./autogen.sh --noconfigure in /home/knut/sources/lily ... succeeded after 1 seconds exec ../configure --prefix=/home/knut/sources/lilybuilt/ in

Re: broken doc build (orchestra.ly)

Am 20.05.2016 um 15:50 schrieb Knut Petersen: Am 20.05.2016 um 14:20 schrieb David Kastrup: Knut Petersen <knut_peter...@t-online.de> writes: Hi everybody! Building the current git lilypond binary succeeds, but building the documentation is broken even if I try a single core

Re: broken doc build (orchestra.ly)

Am 20.05.2016 um 17:27 schrieb David Kastrup: David Kastrup writes: Can you run this under a debugger and place a breakpoint on Scheme_engraver::init_from_scheme or just write abort(); as its first line? I want to know whether the problem is triggered _without_ creating a

Re: C++ question:

Hi David! Sigh. Why do you use set_empty _after_ translation? That makes the remaining point stick out from the actual glyph. And of course, it totally moots any effect of set_empty before translation. It does not matter where set_empty is used, it does not have the desired effect. I tried

Re: [PATCH] no-outline-stencil backend property

Am 24.01.2017 um 14:49 schrieb David Kastrup: What a steaming heap of something. So your code would likely have worked in LilyPond 2.16. I think it would make sense to create a new type of stencil expression explicitly intended to bypass outlining. Probably by just containing _two_ stencils:

Re: C++ question:

// A markup property whiteout-markup-wzd is implemented. // The following definition is used for that property: // \markup { \with-dimensions #'(0 . 0) #'(0 . 0) { // \filled-box #'(0.0 . 1.0) #'(-0.5 . 0.5) #0.0 } } SCM properties =

[PATCH] no-outline-stencil backend property

. That would make for a much more transparent manner of programming things like that. There's no need for two stencils. I propose to include the attached code. Knut >From ae50c298fee5f57c1200bd82b8f20783e74b4cd9 Mon Sep 17 00:00:00 2001 From: Knut Petersen <knut_peter...@t-online.de>

C++ question:

Hi everybody! Is there an equivalent of \with-dimensions #'(0 . 0) #'(0 . 0) that can be used on a stencil within the C++ part of lilypond? If not: I thought I could work around that problem by constructing and using a markup: SCM properties =

Re: Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)

identically. But yes, it should be SCM_UNSPECIFIED. Knut >From 7c89c556ca985925755c892873e787b9f223a5c3 Mon Sep 17 00:00:00 2001 From: Knut Petersen <knut_peter...@t-online.de> Date: Wed, 18 Jan 2017 16:37:36 +0100 Subject: [PATCH] Change EXTENDER return value in parser Signed-off-by: Knut

Re: C++ question:

Am 20.01.2017 um 13:35 schrieb David Kastrup: Knut Petersen <knut_peter...@t-online.de> writes: Hi David! Uh what? If you want to change the dimensions of a stencil copy, you can just do Stencil wd0 = orig; wd0.set_empty (false); I use the following code to emit hyphens (sten

Re: C++ question:

Hi David! Uh what? If you want to change the dimensions of a stencil copy, you can just do Stencil wd0 = orig; wd0.set_empty (false); I use the following code to emit hyphens (stencil ds) and whiteout boxes (stencil ws) in lyric-hyphen.cc: Stencil total; for (int i = 0; i < hyphens;

Re: Back in the Pond

Hi everybody! +1. A personal wish: I think that \lyricsto ChoirStaff = "ctx" { ... } has the potential to be a killer feature w.r.t. usability for choir literature (especially combined with the upcoming automatic extenders). Unfortunately, assignment of lyrics to *container* contexts does not

Re: Back in the Pond

The autoextender patch only adds extenders at places where extenders can be added without it. That does not sound like we should remove __ from lyrics to me. I don't understand that comment. With the autoextender patch there will be an extender if a melisma is detected and there is enough

How can I read/use properties of LyricText while processing LyricHyphen?

Hi everybody! To solve issue 1255 I added a "use-markup" and a "text" property to LyricHyphen and changed lyric-hyphen.cc to use Text_interface::print if the use-markup property is true. That works, but one question remains: If I use font overrides I need to use the same overrides for both

Re: How can I read/use properties of LyricText while processing LyricHyphen?

Am 06.10.2016 um 11:04 schrieb Simon Albrecht: Hi Knut, thanks for taking this on! On 06.10.2016 09:11, Knut Petersen wrote: To solve issue 1255 I added a "use-markup" and a "text" property to LyricHyphen and changed lyric-hyphen.cc to use Text_interface::print if the

BUG: Lilypond forgets to draw barline spanner after \bar ""

Hi everybody! As far as I understand after \bar "" a \break is permitted in the middle of a bar. Lilypond is supposed to engrave the next barline at the proper place. At the marked places ( FIXME/ BUG) in the attached score lilypond needs to be forced to print a barline ... I think this is a

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

Am 19.09.2016 um 14:29 schrieb Simon Albrecht: Sorry, Knut, but this is a totally inacceptable report. It’s not clear what you want, and you come up with an example of 300+ lines of code. There are times where you cannot see the wood for the trees. I posted the original mail because I was

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

Am 19.09.2016 um 14:29 schrieb Simon Albrecht: Sorry, Knut, but this is a totally inacceptable report. It’s not clear what you want, and you come up with an example of 300+ lines of code. There are times where you cannot see the wood for the trees. I posted the original mail because I was

Re: guile-2.0 and debian

Am 25.11.2016 um 23:19 schrieb Antonio Ospite: stuff to simplify the workflow, attracting more people. It's still tedious to add Antonios patches. How about creating a public branch? I could do this in the evening (if I remember the syntax) What do you think? Shouldn't most of them be able

Re: guile-2.0 and debian

Hi Antonio! TBH I didn't try to compile lilypond using guile-1.8 with my patches applied, I can give it a go in the next days. I added your patches in numerical order as single commits to my local branch on top of current master and started a "git bisect run" process to investigate which of

lilypond, guile 2 and OpenSuSE

Hi everybody! Status of guile on OpenSuSE distributions: == OpenSuSE Tumbleweed includes guile 2.0.13 since 2016-10-15. OpenSuSE Leap does include guile 2, but the version is too old to support lilypond. Manual installation of the guile 2 version from

Re: guile-2.0 and debian

Hi Jan-Peter! And about the choice between guile 1.8 or 2.0.12/13, it should be possible to have both guile-1.8 and guile-2.0 packages installed in the same image and then let lilypond choose which one to pick up at configure-time, shoudln't it? I doubt that. You can install guile 1.8 and 2.0

Re: Whiteout / LyricHyphen

Am 26.09.2016 um 13:14 schrieb Knut Petersen: Therefore I propose that LyricHyphen grobs should implement their own whiteout routine. That would give the desired result with a minimum of effort (see 3rd and 4th attachment). Nobody interested

Re: Whiteout / LyricHyphen

Am 02.11.2016 um 21:36 schrieb Carl Sorensen: I spent a bit of time thinking about better ways to do it, and couldn't come up with any. We would need a grob for every hyphen, not a single grob with 1..n hyphens. Not a trivial task, afais. cu, Knut

music function to be included somewhere in scm/*

Hi everybody! There is a discussion on lilypond-user with the target to allow automated lyric extenders to lilypond. One part of that is a patch to clean and extend lyric_extender.cc. To allow automated creation of lyric extenders a helper function is needed. Putting the following code into a

Re: music function to be included somewhere in scm/*

Hi Urs! My gut feeling says: Yes, this is an improvement and should be there by default. IIUC the reason why this has to be discussed is because that could change/break existing scores, right? If so, could you please think about an example where the patch would have a negative impact that can't

Re: music function to be included somewhere in scm/*

Hi Werner! Nice! However, I'm not happy with the name `minimum-length': It implies that this value sets the minimum length of extender lines, which is not true. What about `minimum-space' or `show-length'? minimum-length has been a property of the engraver for a long time. It never

Re: music function to be included somewhere in scm/*

Hi Alexander et. al.! For me scheme still is the most counterintuitive way to program a computer. I believe that I discovered a thousand ways to trigger the message "[...] warning: Ignoring non-music expression". Could we switch to something easy like postscript or x86 assembly? ;-)) As your

Re: music function to be included somewhere in scm/*

Am 15.12.2016 um 17:19 schrieb Trevor Daniels: Currently, I set minimum-length = 0 in all Lyric contexts so that I can place identical lyrics in several voices, all with extenders, but the extenders appear in the score only when they correspond to melismata. In other words the extender is

Re: music function to be included somewhere in scm/*

Hi Trevor, Another common use case occurs when the lyrics in several verses have melismata in different places. This is usually indicated with dashed slurs, occasionally even with two such slurs starting on the same note. When there are many of these the easiest way is simply to turn off

Re: music function to be included somewhere in scm/*

Am 15.12.2016 um 16:46 schrieb Werner LEMBERG: We have convert-ly exactly for such changes. I doubt that all corner cases like the Issue 1006 update given in lyrextest.ly can be handled automatically ... cu, Knut ___ lilypond-devel mailing

Re: music function to be included somewhere in scm/*

Hi Urs! I'd suppose that within words hyphens are implicitly created like before? Yes. Nothing in this patch touches the hyphen engraver ... cu, Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org

Re: music function to be included somewhere in scm/*

Am 15.12.2016 um 17:17 schrieb Francisco Vila: Excuse my brevity for now, but I think lyrics extenders are meant only for the last syllable of a word. What does Gould say, for example? I can check later, @home. I don't know what Gould says, but you are right. Nothing else is proposed. Knut

Re: music function to be included somewhere in scm/*

Am 15.12.2016 um 19:29 schrieb Werner LEMBERG: We have convert-ly exactly for such changes. I doubt that all corner cases like the Issue 1006 update given in lyrextest.ly can be handled automatically ... ??? s/LyricExtender.minimum-length/LyricExtender.whatever-you-want/ Yes, that would be

Re: music function to be included somewhere in scm/*

Am 16.12.2016 um 14:38 schrieb Urs Liska: As your knowledge of scheme seems to be well developed, could you give a scheme equivalent of forceExtender = { \once \override LyricExtender.force-extender = ##t } that is acceptable to lilypond? #(once (overrideProperty '(LyricExtender

Re: music function to be included somewhere in scm/*

Am 14.12.2016 um 18:03 schrieb Simon Albrecht: On 14.12.2016 14:54, Knut Petersen wrote: With a music function \autoextenders that adds extender events to every syllable you - can be sure never to forget extenders, - can be sure never to generate too short extenders - can use the same lyrics

Re: music function to be included somewhere in scm/*

would need some work, but there is no reason to start with that until it is known that the changed code would be accepted. Please test ... cu, Knut >From 53e80c9c17cfa2b11deb15ccfef4587b82c06d52 Mon Sep 17 00:00:00 2001 From: Knut Petersen <knut_peter...@t-online.de> Date: Thu, 15 Dec 2016 1

Re: music function to be included somewhere in scm/*

Hi Paul, Alexander et. al! I need to be very short as a rehearsal is waiting. I'd advocate to keep minimum-length. I also need some way to force an extender and to inhibit extender generation. Forcing an individual extender should overrule a general inhibition of extenders. Details can be

request: user account for lilypond issue tracker

Life would be a bit easier if someone could give me an user account for the issue tracker. Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [2.20] Issue 4943 Manual page breaking causing assertion failure using Windows

Hi everybody! On 64-bit Linux I also saw failures caused by manual page breaking with too few space a few months ago. I had no time to investigate the problem then, but there definitely is a problem not only on windows. I saw assertion failures, but I also managed to immediately kill lilypond

Re: Delete new LSR-snippet?

Hi Thomas! Thanks Knut for your code. Though, this snippet will produce bad output as soon as something like a key-change happens at the line-break. True. If someone really needs marginal notes, the attached example shows a better way ... use TeX & lilypond. The code needs a recent lilypond

Re: Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)

cm changed according to you comment. @Trevor: vocal.itely changed according to your comments. Cheers, Knut >From 37acebbdfb8876ca5ef94d473f4cfc234c4e8bd2 Mon Sep 17 00:00:00 2001 From: Knut Petersen <knut_peter...@t-online.de> Date: Sun, 1 Jan 2017 16:16:24 +0100 Subject: [PATCH] Autom

Re: music function to be included somewhere in scm/*

Hi Werner! (length-limit-or-forced-length ,ly:dimension? "An automatically generated lyric extender is suppressed if it would be shorter than this length. A forced lyric extender is given this length if possible.") Sorry, but I strongly dislike collapsing two properties into one, even if

Re: music function to be included somewhere in scm/*

I'd advocate to keep minimum-length. I second the vote for collapse-length. Ok, next try: s/minimum-length/length-limit-or-forced-length/g (length-limit-or-forced-length ,ly:dimension? "An automatically generated lyric extender is suppressed if it would be shorter than this length. A

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

by the attached patch (they were masked by some other code in my private git tree). cu, Knut >From 50d9ab59c3c332578f338ea5ff01427a4ae553e8 Mon Sep 17 00:00:00 2001 From: Knut Petersen <knut_peter...@t-online.de> Date: Fri, 23 Dec 2016 23:44:30 +0100 Subject: [PATCH] Lyric autoextenders: Sil

Re: Delete new LSR-snippet?

Hi Trevor! I seem to remember a post or maybe an LSR entry for placing divisi arrows at the end of a staff. Maybe this could be adapted to achieve the same effect more reliably? Found it - LSR 650. It modifies the barline stencil. Something like the following code could be a base:

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

Hi Alexander et al.! As extender events are generated automatically now it probably is a good idea to tell yacc / bison to recognize but ignore "__" tokens. cu, Knut >From 768bf54ad8563b0cb6c2cbce692385656db3a535 Mon Sep 17 00:00:00 2001 From: Knut Petersen <knut_peter...@t

Re: Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)

Hi everybody! I'm only 90% happy about "" and \markup\null... For dynamic spanners and hairpins, we have \! to end them prematurely before a "natural" end event appears. Is this similar enough to warrant the use of the same token (i.e., \! would be translated to empty lyrics with a

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

Am 25.12.2016 um 13:14 schrieb Noeck: As extender events are generated automatically now it probably is a good idea to tell yacc / bison to recognize but ignore "__" tokens. I don't know at which level the __, \overrides and the automatic extenders interact. But would it make sense to use __

Re: Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)

Am 27.12.2016 um 03:01 schrieb perpeduumimmob...@gmail.com: On 2016/12/26 19:14:00, pkx166h wrote: On 2016/12/25 21:53:55, akobel wrote: > Bottom line: I withdraw both proposals. Can you then re-submit a new patch or delete the one(s) that are invalid? Sorry, I'm a bit drawn up between my

[PATCH] Automatic lyric extenders

Hi everybody! Attached find a new version of the patch. Please test. Read the updated manuals. Feel free to provide corrections and translations! cu, Knut >From 0c05e1385ea9658b32b16aafbedfa10a1e7a041e Mon Sep 17 00:00:00 2001 From: Knut Petersen <knut_peter...@t-online.de> Date: Th

Re: [PATCH] Automatic lyric extenders

Hi Alexander et al.! how about putting the patch on Rietveld? I agree that this should go into a normal patch review process now. Knut, are you familiar with the git cl proceedings? If not, it’s explained in the CG 1.3 and 2.3. +1. Let us know if you need help. I went through the procedure

Re: [PATCH] Automatic lyric extenders

Hi Werner! One nit: Please avoid overlong lines in the source code; it should be limited to 80 characters per line to improve legibility. Well, a number of lines are longer than 80 characters, but most are shorter than their predecessors. If the 80 character limit should be obeyed, it would

Exportig lilypond music events and correlate it to real recordings?

Hi everybody! Given there is a) a lilypond score and b) a recording of the music described in the score. It's easy to export the music events from the score, it's also easy to feed the music to a fft. Does anyone know of any existing software to correlate these two datasets? Lilypond music

Re: Some questions related to score video generation

Hi Urs! If nh is the name of your grob in the callback then (ly:grob-object nh 'stem) will give you the stem. AFAIK the Flag etc. are not all accessible this way but you can do Thanks a lot for pointing the way to ly:grob-object. In fact it does work for stems, flags and dots. Knut

Re: Some questions related to score video generation

Am 07.07.2017 um 12:04 schrieb Knut Petersen: There is a new version of the demonstration video online: I Fyrreskoven. <https://www.youtube.com/watch?v=hgDWprKiyo0> Coloring of stems / flags /dots works now. Knut ___ lilypond-devel mailin

Re: Some questions related to score video generation

Am 09.07.2017 um 00:18 schrieb Karlin High: Knut Petersen wrote I extended my video generation script to allow coloring notes as they are played. Is the updated script publicly available someplace? I found a lilypond-user thread from September 6, 2016 that appears to have an earlier version

Duplication of pages with slight changes to color of grobs?

Hi everybody! I'd like to ask a questions: A) Is there a practical way to duplicate pages (with slight changes to the color of grobs) from within an procedure activated by the after-line-breaking hook or at another place after page breaking without changes to lilyponds own scm files? If that

Re: Duplication of pages with slight changes to color of grobs?

Hi Paul! B) Is there a practical way to redefine color? within a .ly file in a way that it is recognized by lilyponds code? I take it you have tried this? #(define (color? ...) ...) ;-) Also "#(set! " does not help ... Would it help to define your own custom properties (grob or

Re: Duplication of pages with slight changes to color of grobs?

Hi David! Would it help to define your own custom properties (grob or context) to avoid overloading the color property. I have this in my include file for Clairnote: Interesting approach ... I think it would only shift the problem to other places in the code. Well, but they might be less

[PATCH] Some hooks useful for video production

Hi everybody! The attached patch implements some hooks that would allow my video generation script to work without the requirement to patch some of lilyponds scm and ps files. Knut >From 230ad4aa3126562ab9ae87c891f7fe965c64a9de Mon Sep 17 00:00:00 2001 From: Knut Petersen <knut_pete

after-line-breaking access to paper variables

Hi everybody! I use some scheme code to dump information needed for video generation: #(define (mkvideo-dump-alb grob) (let* ( (pap (ly:parser-lookup '$defaultpaper)) (lm (ly:output-def-lookup pap 'left-margin)) [...] It is activated by

Re: after-line-breaking access to paper variables

Hi David! At any rate, you are overriding grob callbacks, and maybe you just want to call (lm (ly:output-def-lookup (ly:grob-layout grob) 'left-margin)) and its ilk? Thanks a lot, that's exactly what I needed! Knut ___ lilypond-devel mailing list

Re: [gs-devel] Ghostscript/GhostPDL 9.22 Release Candidate 1

Am 19.09.2017 um 02:27 schrieb Perry Hutchison: There is a tool for using this method of removing duplicate fonts. https://www.ctan.org/pkg/extractpdfmark https://packages.debian.org/stretch/extractpdfmark http://packages.ubuntu.com/zesty/extractpdfmark As I see it, the availability of a

Re: [gs-devel] Ghostscript/GhostPDL 9.22 Release Candidate 1

Am 19.09.2017 um 04:12 schrieb William Bader: pdfsizeopt is another pdf compression tool that can eliminate duplicate fonts and can sometimes merge subset fonts. https://github.com/pts/pdfsizeopt/blob/master/lib/pdfsizeopt/main.py I checked pdfsizeopt more than once. Unfortunately it never

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

Hi everybody! So you aren't gaining any benefit from exploiting the Ghostscript bug with the Lilypond output. But we are. I hope that Masamichi-san (or Kurt?) can provide the details here in order to give you a better picture. * *Some technical details about our usage of the bug/feature we

Re: [gs-devel] Ghostscript/GhostPDL 9.22 Release Candidate 1

Am 18.09.2017 um 20:20 schrieb Ken Sharp: LilyPond has option `--bigpdfs` for unifying duplicate fonts in this method. And your point is what ? That's not what the pdfwrite device is intended for, and we don't claim you can use it to do that. As I said, if you think its that useful, then you

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

Hi everybody! The removal of the PDFDontUseFontObjectNum option in ghostscript caused a lot of headache during the last days. Lilypond provides since early 2015 a way to persuade ghostscript to remove duplicated fonts from pdfs. Later the extractpdfmark program was introduced to allow links

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

Well, it occurs to me that the *real* problem here is that the fonts in the individual PDF files are subsets. If they were not, then I believe you could safely and easily use MuPDF (specifically mutool clean) to remove the duplicate fonts. Or at least, the duplicate FontFile streams, I'm not

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

Am 20.09.2017 um 09:50 schrieb Ken Sharp: If someone can create a couple of PostScript files, ideally genuine examples of the files you would use for your manual, created as you would create them for the manual (ie with the bigpdf switch) then I can experiment a bit. I don't need any PDF files,

  1   2   3   >