Re: Doc update for section 7.5
On 16-Apr-06, at 1:58 PM, Erlend Aasland wrote: Since I happen to play guitar, I've cooked up some updates for the tablature section in the docs (section 7.5.2 and 7.5.3). Please see the attached patch. (Warning: I'm no expert in writing english documentation...) Thanks! I changed a few sentences slightly, but they were only minor things -- the docs look great! I've committed it to CVS. - Graham (as you probably found out, the shaw address does not work any more) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is %%PageMedia: a4 hardcoded?
Hi, On Sun, 16 Apr 2006, John Hawkinson wrote: Johannes Schindelin [EMAIL PROTECTED] wrote on Sun, 16 Apr 2006 at 13:46:16 +0200 in [EMAIL PROTECTED]: +(display \n%%BeginDefaults +%%PageMedia: a4 +%%EndDefaults\n port) Correct me if I'm wrong, but was BeginDefaults not the method of choice to say: if no other value is given, please take A4 instead of that awkward Letter format? No, that's not what it is at all. You may find it instructive to refer to the specification. http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf Thanks for the clarification. And BTW, Lily's PostScript code's main purpose is to produce something which Ghostscript turns into a PDF. So, the PostScript does not have to adher strictly to the specs, but to what Ghostscript understands. Yikes, really!? That's good to know, I guess, but also kind of disappointing. For some reason that I have not bothered to debug, PDFs that LilyPond (2.6.3) generates for me have bizarre defects, like all text turning into the letter y, etc. As such, postscript is the way to go. Not to mention that it's faster. If I sounded like your work was not valuable, I made myself misunderstood. It sure would be a fine thing if the PostScript could be sent to a PostScript printer without problems. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug in the new PS code
On 4/17/06, David Feuer [EMAIL PROTECTED] wrote: On 4/16/06, Erlend Aasland [EMAIL PROTECTED] wrote:This should only be necessary for the draw_dashed_line procedure.Thedraw_dashed_slur one brackets its operations with gsave/grestore. Yes, of course, I didn't notice :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Move rotated_box ()
Hi Jan,Can I apply this patch?Regards, Erlend Aasland rotated_box.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Best way to format nested lists
On 4/17/06, Cameron Horsburgh [EMAIL PROTECTED] wrote: For example the example given puts the relevant line in one long line: \set StaffGroup.systemStartDelimiterHierarchy = #'(SystemStartSquare (SystemStartBracket a (SystemStartSquare b)) d) Even small examples will wrap, making the whole thing messy and difficult to understand. I presume this is a Scheme like construction -- how do deeply nested lists get formatted there? Different people do different things, but generally something like this: \set StaffGroup.systemStartDelimiterHierarchy = #'(SystemStartSquare (SystemStartBracket a (SystemStartSquare b)) d) You might want to use an editor, such as Vim, that can do automatic indentation of LilyPond files. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gregorian chant improvement
By the way, you may also be interested in the following related work from a workshop on Braille Notation of Psalmodia and Gregorian Chant, held in Marburg, Germany, on October 2-3, 2002: http://www.sbs-online.ch/musik/conference/documents/gregor.pdf In order to make Gregorian chant notation readable for blind people, the authors define how to decompose complex neumes into primitives, which in turn are mapped to braille. In fact, their breaking-down approach is very similar to what lily does, such that it should not be too complicated to implement their specification as an extension to LilyPond (which would probably be a nice student project). Greetings, Juergen On Tue, 21 Mar 2006, Elie Roux wrote: ... But in my work with the monk we discovered that the most simple was to decompose neumes in simpler elements. We are able to list all the simple elements, and so we can make all possible neumes. It would be much simpler I think, than listing all possible neumes. It would also permit to put quilismas everywhere, not only in pes (they can be at any place in most of neumes). If you want more details about these simple elements tell me, I will translate a document I made about a XML schema for gregorian chant (in french on http://omega.enstb.org/eroux/doc_fr.pdf). ... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Separation_item problem
Hi,
I have been trying to fix the misplaced dot bug in Gregorian chant
notation -- without sucess:
void
Vaticana_ligature_engraver::add_mora_column (Grob *parent)
{
if (!parent) // empty ligature
return;
if (augmented_primitives_.size () == 0) // no dot for column
return;
Item *dotcol = make_item (DotColumn, SCM_EOL);
for (vsize i = 0; i augmented_primitives_.size (); i++)
{
Item *dot = make_item (Dots, augmented_primitives_[i]-self_scm ());
dot-set_parent (augmented_primitives_[i], X_AXIS);
dot-set_parent (parent, Y_AXIS);
dot-set_property (Y-offset, Grob::x_parent_positioning_proc);
augmented_primitives_[i]-set_object (dot, dot-self_scm ());
Axis_group_interface::add_element (dotcol, dot);
Side_position_interface::add_support (dot, augmented_primitives_[i]);
Pointer_group_interface::add_grob (dot, ly_symbol2scm (note-heads),
augmented_primitives_[i]);
Dot_column::add_head (dotcol, augmented_primitives_[i]);
}
}
The above code should create a dot column, which should be horizontally
placed immediately behind Grob *parent. The dot column should consist of
a number of dots, one for each notehead grob held in the
vectorItem * augmented_primitives_
variable.
The only thing that this code produces is a Separation_item: I've been
drinking too much error, and no dot is printed.
Once, when writing the porrectus engraver, I had similar problems, and as
the cause, I suspected the discrepancy between the column of the music
cause and the column of where to print the outcome. This discrepancy is
also true in the above code: the notehead, which is the cause of the dot,
may arise earlier in time than the column where the dots are collected.
Has someone an idea how I can fix this problem?
Greetings,
Juergen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is %%PageMedia: a4 hardcoded?
The changes were made with hints from the GSview author, with the primary purpose of making GSview grok the code. I readily admit that my postscript knowledge is virtually nonexistent. Feel free to submit patches to make lily create sane PS. 2006/4/16, John Hawkinson [EMAIL PROTECTED]: And BTW, Lily's PostScript code's main purpose is to produce something which Ghostscript turns into a PDF. So, the PostScript does not have to adher strictly to the specs, but to what Ghostscript understands. Yikes, really!? That's good to know, I guess, but also kind ofdisappointing.For some reason that I have not bothered to debug,PDFs that LilyPond (2.6.3) generates for me have bizarre defects, likeall text turning into the letter y, etc. As such, postscript is the way to go. Not to mention that it's faster.___lilypond-devel mailing listlilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Whither the switch to OpenType fonts? (they break my printer)
I mentioned in a separate thread (Why is %%PageMedia: a4 hardcoded?)
some problems with LilyPond's Postscript hanging my printer (as of
2.7.38 and later; 2.7.36 and prior worked fine).
At first, I presumed that this was a result of having a potentially
non-8-bit clean path to my printer because of site-local spooling
system issues, but I've verified that's not the case (spooling files
to the printer directly with netcat, etc.).
It seems that the binary OTF encodings of both Aybabtu-Regular and
Emmentaler-18 give this problem. Going and hand-editing the postscript
and replacing the OTF versions with the type1 versions (and renaming
the references to the fonts from Aybabtu-Regular to
PFAAybabtu-Regular, etc.,) produces a file that works fine (though it
is 26% larger).
How does it crash the printer? Well, various ways. Most clearly is
that sometimes it produces a 79.00FE crash on the front panel, and
other times it simply hangs the printer such that it does not respond
to input over the network or on the front panel. I haven't pursued it
with HP, but they do have a history of having a myriad of such
problems with strange binary encodings. The printer in question is an
HP8150DN (of which we have a whole slew around here) running the most
recent firmware (20041013 MB7.119).
One workaround I tried was to convert the fonts to hex, and wrap their
encoding in:
currentfile /ASCIIHexDecode filter cvx exec
%...hex of the font here...
This does not work. It seems to work for Aybabtu, but not for
Emmentaler, which causes an error even with ghostscript. (Error:
/invalidfont in --.type42execchar--) I'm not sure why...
So anyhow:
. Can LilyPond go back to Type 1 fonts in the interest of
broader compatibility? Or perhaps this could be an option (but
they would have to be generated at build time, anyhow). On the
other hand, is there anything to be gained by OTF fonts?
having the PS files a bit smaller probably doesn't matter for
the ghostscript ps-pdf conversion, and doesn't seem a big price
to pay for better compatibility.
. Why do the different encodings (Type1 PFA, OTF) produce
differing-named fonts (PFAAybabtu-Regular vs. Aybabtu-Regular)?
[hence the necessity for munge-lily-font-name].
It seems like this has potentially been a problem before.
Revs 1.84 through 1.86 of scm/framework-ps.scm share this log message
tidbit:
* scm/framework-ps.scm (munge-lily-font-name): new function
(write-preamble): hack: insert PFA equivalent of CFF into
.PS. This makes LilyPond output printable on normal PS printers
again.
I suppose that I could attempt to take up this issue with HP,
and perhaps get it fixed in a new firmware version half a year
from now (not that they've released any in the past 2 years),
but I must say I'm not enthusiastic.
In that other thread, [EMAIL PROTECTED] wrote on Mon, 17
Apr 2006 at 13:14:03 +0200 in
[EMAIL PROTECTED]:
It sure would be a fine thing if the PostScript could be sent to a
PostScript printer without problems.
Great!
--jhawk
John Hawkinson [EMAIL PROTECTED] wrote on Sun, 16 Apr 2006
at 21:34:22 -0400 in [EMAIL PROTECTED]:
Date: Sun, 16 Apr 2006 21:34:22 -0400
From: John Hawkinson [EMAIL PROTECTED]
To: lilypond-devel@gnu.org
Message-ID: [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
Subject: Re: Why is %%PageMedia: a4 hardcoded?
I [EMAIL PROTECTED] wrote (quite a few hours ago...) on Sun, 16 Apr 2006
at 10:55:43 -0400 in [EMAIL PROTECTED]:
p.s.: In moving from LilyPond 2.6.3 to 2.9.2, I find that spooling
postscript crashes my HP LaserJet 8150DN. Haven't finished
figuring out why yet... I'll get there...
It appears that this broke between 2.7.36 and 2.7.38,
and it seems to be a result of the massive font changes
that happened therein (apparently moving to embedding
opentype fonts instead of Type 1 fonts?).
I can't seem to find a discussion of the rationale for all of this on
lilypond-{user,devel} or bug-lilypond. Am I just missing it, or could
someone point me to the discussion?
Perhaps it has something to do with my print spooling environment, but
it seems like the non-eight-bit-clean nature of the generated
PostScript is likely to be my problem...
Thanks for any pointers...
--jhawk
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
