Re: anyone notice speed of 2.17.95 on Windows ?
Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). Inserting print statements to trace those calls I find that FT_Get_Name_Index is called: 7 times for each character in a Tempo 5 times for each character in a Text Script ... 1 time for each notehead 5 times for each rest Ouch. `FT_Get_Name_Index' is quite a slow function, indeed, so caching its results would speed up things a lot. Note that speeding up the function itself was never on my radar – in all the years I'm working on FreeTpye there was not a single request to do so, IIRC. Modern fonts use the SFNT container format, centered around glyph indices, not glyph names. In other words, looking up glyph indices from glyph names is not a central function in most cases. I will check whether I can improve that in FreeType. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Werner LEMBERG w...@gnu.org writes: Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). Inserting print statements to trace those calls I find that FT_Get_Name_Index is called: 7 times for each character in a Tempo 5 times for each character in a Text Script ... 1 time for each notehead 5 times for each rest Ouch. `FT_Get_Name_Index' is quite a slow function, indeed, so caching its results would speed up things a lot. Note that speeding up the function itself was never on my radar – in all the years I'm working on FreeTpye there was not a single request to do so, IIRC. Modern fonts use the SFNT container format, centered around glyph indices, not glyph names. In other words, looking up glyph indices from glyph names is not a central function in most cases. I will check whether I can improve that in FreeType. Is there a reason this would have such a significantly different impact in Windows? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
I will check whether I can improve that in FreeType.
Is there a reason this would have such a significantly different
impact in Windows?
No. It's exactly the same code on both platforms. However, for
lilypond, even a single-element cache would help, see attached
quick'n'dirty patch (for FreeType).
Werner
diff --git a/include/internal/tttypes.h b/include/internal/tttypes.h
index ad302b8..dfbb303 100644
--- a/include/internal/tttypes.h
+++ b/include/internal/tttypes.h
@@ -1402,6 +1402,9 @@ FT_BEGIN_HEADER
FT_Bool sph_compatibility_mode;
#endif /* TT_CONFIG_OPTION_SUBPIXEL_HINTING */
+FT_String*cached_glyph_name; /* a single-element cache */
+FT_UInt cached_glyph_name_index;
+
} TT_FaceRec;
diff --git a/src/sfnt/sfdriver.c b/src/sfnt/sfdriver.c
index e0132c9..c8097b5 100644
--- a/src/sfnt/sfdriver.c
+++ b/src/sfnt/sfdriver.c
@@ -186,6 +186,10 @@
FT_TRACE0(( Ignore glyph names for invalid GID 0x%08x - 0x%08x\n,
FT_UINT_MAX, root-num_glyphs ));
+if ( face-cached_glyph_name
+ !ft_strcmp( glyph_name, face-cached_glyph_name ) )
+ return face-cached_glyph_name_index;
+
for ( i = 0; i max_gid; i++ )
{
FT_String* gname;
@@ -196,7 +200,12 @@
continue;
if ( !ft_strcmp( glyph_name, gname ) )
+ {
+face-cached_glyph_name = gname;
+face-cached_glyph_name_index = i;
+
return i;
+ }
}
return 0;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
Incorporated most of the comments.
Will upload new patch set in a minute
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi
File Documentation/web/download.itexi (right):
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode38
Documentation/web/download.itexi:38:
On 2013/12/13 06:00:09, J_lowe wrote:
Is this whole section conforming to the correct line length - 72 (or
66) chars?
At least here in Rietveld it looks sloppy with weird line breaks.
Maybe this is
just the way it is displayed here but can we make sure please.
Done.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode40
Documentation/web/download.itexi:40: @subheading Before you proceed ...
On 2013/12/13 06:00:09, J_lowe wrote:
I don't like those elipses and they aren't really needed (or being
used
correctly, they are for missing words and anyway there is a texinfo
command for
'dots'.) can we just have 'Before you proceed' and be done?
I'm OK with this kind of edits.
But I'd like to point out that I copied the chatty style from quite
some existing texts on the website:
Just a few examples:
- I want to see some music!
- Yep, it's free.
Done.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode42
Documentation/web/download.itexi:42: ... you should be aware of some
facts and concepts.
On 2013/12/13 06:00:09, J_lowe wrote:
Remove this '... you should be aware of ...' line. Subheading is
enough.
Done.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode50
Documentation/web/download.itexi:50: If you want you can go to @ref{Text
input} and learn more about LilyPond's
On 2013/12/13 06:00:09, J_lowe wrote:
What happens if they 'don't want?' Remove the 'If you want you can go
to'
Just keep it simple. I.e 'See @ref{Text input} to learn more.'
Done.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode53
Documentation/web/download.itexi:53: @subsubheading I'm new to LilyPond
and don't have a dedicated editor yet
On 2013/12/13 06:00:09, J_lowe wrote:
I personally don't like these 'first person' question-type headings,
but if we
have to have them can we just remove the 'I'm new to LilyPond' and get
to the
point.
Something like 'Which dedicated LilyPond Editor' or similar.
I think in this case we *should* get to this colloquial style. It seems
to be necessary because too many people have got this wrong, presumably
because they didn't really bother to read.
However I've switched to a You address.
Done.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode55
Documentation/web/download.itexi:55: If you don't already have an
editing environment for LilyPond you should
On 2013/12/13 06:00:09, J_lowe wrote:
You had already subheaded this section as '[I] ... don't have a
dedicated
editor...' so these first words are redundant. Just skip to the point.
See @ref{Editing} to find a list of LilyPond editors. Frescobaldi or
Denemo are
recommended for beginners.
Done.
https://codereview.appspot.com/40510046/diff/20001/Documentation/web/download.itexi#newcode64
Documentation/web/download.itexi:64: to install a new LilyPond version
you can proceed as described below.
On 2013/12/13 06:00:09, J_lowe wrote:
Is this section even needed?
I think yes. This should step in the way of a new user who'd (out of a
habit) jump directly to the Download buttons.
https://codereview.appspot.com/40510046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
Thanks for what you're doing, but please don't put a lot of images on the Google Issue tracker. For bizarre reasons only known to themselves, the storage available for attachments is _very_ limited. By accident you've just used about 1/25 of our remaining quota. -- Phil Holmes - Original Message - From: Carl Peterson To: Carl Peterson Cc: Lilypond Dev Sent: Thursday, December 12, 2013 10:58 PM Subject: Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048) On Thu, Dec 12, 2013 at 1:06 AM, carlopeter...@gmail.com wrote: Message: Patch for initial solution to issue 3714, regarding color-coding of manuals. Please review this at https://codereview.appspot.com/36480048/ I have submitted follow-up patches to Rietveld to address comments regarding the duplicate CSS definitions. I also found where a change to simplify the manual-specific definition caused a problem with the default color choices (when a specific color set has not been defined), and have corrected this. For those who need a visual of these changes, I've uploaded screenshots to the Google Code issue. https://code.google.com/p/lilypond/issues/detail?id=3714. Regards, Carl P. -- ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
On 13/12/13 13:04, Phil Holmes wrote: Thanks for what you're doing, but please don't put a lot of images on the Google Issue tracker. For bizarre reasons only known to themselves, the storage available for attachments is _very_ limited. By accident you've just used about 1/25 of our remaining quota. -- Phil Holmes - Original Message - *From:* Carl Peterson mailto:carlopeter...@gmail.com *To:* Carl Peterson mailto:carlopeter...@gmail.com *Cc:* Lilypond Dev mailto:lilypond-devel@gnu.org *Sent:* Thursday, December 12, 2013 10:58 PM *Subject:* Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048) On Thu, Dec 12, 2013 at 1:06 AM, carlopeter...@gmail.com mailto:carlopeter...@gmail.com wrote: Message: Patch for initial solution to issue 3714, regarding color-coding of manuals. Please review this at https://codereview.appspot.com/36480048/ What I do when i test patches that have lots of reg test diffs to display is use a service like this: https://www.hightail.com/ This allows me to create a link to a website that user can then download at their leisure For example see: http://code.google.com/p/lilypond/issues/detail?id=3685 comment #2 (it is probably expire now but you'll get the idea). James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
On Fri, Dec 13, 2013 at 8:31 AM, James pkx1...@gmail.com wrote: On 13/12/13 13:04, Phil Holmes wrote: Thanks for what you're doing, but please don't put a lot of images on the Google Issue tracker. For bizarre reasons only known to themselves, the storage available for attachments is _very_ limited. By accident you've just used about 1/25 of our remaining quota. Sorry about that. I'll delete the comment once I've had a chance to make edits to the CSS file and produce new examples. What I do when i test patches that have lots of reg test diffs to display is use a service like this: https://www.hightail.com/ I have ways of linking in images, and have done it on other things. I was just trying to keep everything self-contained within the available services. Now that I realize this is sub-optimal, I will pursue other ways of distributing the screenshots. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
Carl Peterson carlopeter...@gmail.com writes: On Fri, Dec 13, 2013 at 8:31 AM, James pkx1...@gmail.com wrote: On 13/12/13 13:04, Phil Holmes wrote: Thanks for what you're doing, but please don't put a lot of images on the Google Issue tracker. For bizarre reasons only known to themselves, the storage available for attachments is _very_ limited. By accident you've just used about 1/25 of our remaining quota. Sorry about that. I'll delete the comment once I've had a chance to make edits to the CSS file and produce new examples. I seem to remember that deleting comments does not help with the quota. Yes, that seems ludicrous. What I do when i test patches that have lots of reg test diffs to display is use a service like this: https://www.hightail.com/ I have ways of linking in images, and have done it on other things. I was just trying to keep everything self-contained within the available services. Now that I realize this is sub-optimal, I will pursue other ways of distributing the screenshots. Well, it's a trap most people fall in at least once. It's not like that it appears to make a whole lot of sense. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
- Original Message - From: Carl Peterson carlopeter...@gmail.com To: James pkx1...@gmail.com Cc: Lilypond Dev lilypond-devel@gnu.org Sent: Friday, December 13, 2013 2:01 PM Subject: Re: Enable manual-specific styling of documentation;issue 3714(issue 36480048) On Fri, Dec 13, 2013 at 8:31 AM, James pkx1...@gmail.com wrote: On 13/12/13 13:04, Phil Holmes wrote: Thanks for what you're doing, but please don't put a lot of images on the Google Issue tracker. For bizarre reasons only known to themselves, the storage available for attachments is _very_ limited. By accident you've just used about 1/25 of our remaining quota. Sorry about that. I'll delete the comment once I've had a chance to make edits to the CSS file and produce new examples. Unfortunately, deleting them does not remove them from the quota, either! Best to leave them now. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Thu, Dec 12, 2013 at 7:36 PM, carl.d.soren...@gmail.com wrote: I think that the index sidebar colors are too dark. They dominate the page, in my opinon. In the current design, the sidebar color and the highlight box fill color are the same. Why not keep it that way? Attaching another option, to address your concern, as well as Graham's. The background is white, and the sidebar color is actually lighter than the currently-specified highlight box (in the code being reviewed), IIRC. Does this work better? Obviously, this isn't from the actual manuals, but is a mock-up just to see the color relationships. attachment: Color Sheet.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On 12/13/13 8:02 AM, Carl Peterson carlopeter...@gmail.com wrote: On Thu, Dec 12, 2013 at 7:36 PM, carl.d.soren...@gmail.com wrote: I think that the index sidebar colors are too dark. They dominate the page, in my opinon. In the current design, the sidebar color and the highlight box fill color are the same. Why not keep it that way? Attaching another option, to address your concern, as well as Graham's. The background is white, and the sidebar color is actually lighter than the currently-specified highlight box (in the code being reviewed), IIRC. Does this work better? Obviously, this isn't from the actual manuals, but is a mock-up just to see the color relationships. I like this much better. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: Manual-Web
Urs Liska wrote But clicking on Web (split HTML) brings you to a copy of the whole website, just several directories below the original. This is irritating, to say the least. I agree that this does not make sense for someone browsing the website, and the text does not really explain what's going on with this manual very well. Maybe Website instead of Web as a tab/heading would help make things clearer, along with revising the text as you suggest. Another consideration is duplicate content: https://support.google.com/webmasters/answer/66359 As I understand it, best practices (according to Google) is to either minimize or remove such duplicate content or use canonicalization to indicate the preferred / canonical pages: https://support.google.com/webmasters/answer/139066 Usually this works by putting link rel=canonical href=http://www.example.com/etc/etc.html; in the head of any non-canonical page, pointing to the canonical page. I think the links in the other manuals that point to the website manual are done that way so that they will work in a downloaded local copy of the manuals when you are offline. So that makes things tricky. In an offline local copy we have: manuals / website whereas on the website it's: websiteA / manuals / websiteB One possibility: use 301 redirects (in the site's .htaccess file) to point from the pages/urls in websiteB to the same pages/urls in websiteA. Then all the links in the manuals would work as expected both on the website and in local downloaded files. On the website people would always land on the canonical web pages (websiteA), and offline the links would still work fine in local copies of the documentation. Maintenance: the URLs in the 301 redirects would have to be updated with each release of LilyPond since the current version of LilyPond is part of the URLs. Under this scenario you could either keep or remove the link to Web (split HTML). I don't see a reason to keep it, but if you did the 301 redirects would mean it would just take you to the website's home page. -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Website-questions-Manual-Web-tp155674p155727.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
On 12/13/13 6:04 AM, Phil Holmes m...@philholmes.net wrote: Thanks for what you're doing, but please don't put a lot of images on the Google Issue tracker. For bizarre reasons only known to themselves, the storage available for attachments is _very_ limited. By accident you've just used about 1/25 of our remaining quota. I just did a google search for google issue tracker quota. Most of the items that show up are requests for quota increases; as far as I can see none has been turned down. I think we should just go ahead and ask for an increase in the quota; I expect they will grant it to us. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: Manual-Web
Paul Morris wrote Usually this works by putting link rel=canonical href=http://www.example.com/etc/etc.html; in the head of any non-canonical page, pointing to the canonical page. Forgot to say: under the scenario of using 301 redirects you wouldn't need to do any link rel=canonical business since the 301 redirects would prevent the search engines from seeing any duplicate content (at least for those website manual pages that were redirected). -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Website-questions-Manual-Web-tp155674p155729.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
- Original Message - From: Carl Sorensen c_soren...@byu.edu To: Phil Holmes m...@philholmes.net; Carl Peterson carlopeter...@gmail.com Cc: Lilypond Dev lilypond-devel@gnu.org Sent: Friday, December 13, 2013 3:31 PM Subject: Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048) On 12/13/13 6:04 AM, Phil Holmes m...@philholmes.net wrote: Thanks for what you're doing, but please don't put a lot of images on the Google Issue tracker. For bizarre reasons only known to themselves, the storage available for attachments is _very_ limited. By accident you've just used about 1/25 of our remaining quota. I just did a google search for google issue tracker quota. Most of the items that show up are requests for quota increases; as far as I can see none has been turned down. I think we should just go ahead and ask for an increase in the quota; I expect they will grant it to us. Thanks, Carl == I do, whenever we're running out. It's just easier not to have to. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: Manual-Web
- Original Message - From: Urs Liska u...@openlilylib.org To: LilyPond Development Team lilypond-devel@gnu.org Sent: Thursday, December 12, 2013 8:34 PM Subject: Website questions: Manual-Web I've raised this issue already, but I think it needs to be considered in its own thread: What to do with Manuals-Web? When I go there I can download the whole website as a PDF. OK, this makes sense. Getting it as one big HTML page also makes sense. [but where can I get it in info format?) But clicking on Web (split HTML) brings you to a copy of the whole website, just several directories below the original. This is irritating, to say the least. If this page is there for the first two items I mentioned the text in the left box should definitely be clarified. Currently this manual leads the reader to believe that he gets yet one more manual, with some general information. Are there more purposes to that page than providing the PDF and Big HTML versions of the website that I don't see? And there is one more thing I stumbled over (although I don't find an instance of it right now): There are links from within the real manuals that seem to link to the website but actually point to that web manual (i.e. pages below lilypond.org/doc/2.17/web). If there isn't a point I didn't see so far I tend to suggest: - Completely rewrite the Web box on Manuals-Web - Clarify the Read it box and remove the link to Web (split HTML) Does someone have any enlightenment available for me? Urs I _think_ the odd place of web in the manuals hierarchy is down to it being the only part of the documentation that built using make website - it has something of a split personality between being part of the documentation and the website. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Thu, 12 Dec 2013 23:07:19 -0800, Keith OHara k-ohara5...@oco.net wrote: I am happy to say that I was wrong here. Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). Inserting print statements to trace those calls I find that FT_Get_Name_Index is called: 7 times for each character in a Tempo I had failed to notice how the 'pure' calls to vertical-skylines are implemented. Most properties, if directed to a callback function, have result of the callback function replace the pointer to that function. This way the function does its job just once. Sizes of spanners, that do depend on layout but are needed to evaluate potential layouts, are cached in Spanner::get_cached_pure_property() for each combination of 'start' 'end' columns that define the line of music on which they might appear. If the property-lookup is 'pure' (tentative) then usually callback functions are not called. Previously, functions providing stencils of objects whose shape does not depend on page-layout were on a pure-print-callback list, so their shapes could be used during layout decisions. At the moment, there is an unpure-pure-container wrapper around the (expensive) function that builds skylines for text. For some reason this allows repeated function calls to re-compute the property, even when the 'pure' and 'unpure' versions are the same. Somewhere there should be a way to mark the skylines as independent of layout and the method should be used for vertical-skylines of text. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Fri, 13 Dec 2013 01:38:23 -0800, Werner LEMBERG w...@gnu.org wrote: I will check whether I can improve that in FreeType. Is there a reason this would have such a significantly different impact in Windows? No. It's exactly the same code on both platforms. However, for lilypond, even a single-element cache would help, see attached quick'n'dirty patch (for FreeType). The repeated look-ups of the same character, however, are not likely to be successive calls to FT_Get_Name_Index(), so will not find the answer in such a cache. I do see how sfnt_get_name_index() does a linear search through the font to find a matching name. Much better if LilyPond could look up text characters by their Unicode encoding. The issue with Lilypond 2.17.95 is a more complicated than the original case where we noticed that these look-ups took longer on Windows: http://code.google.com/p/lilypond/issues/detail?id=1926 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
I do see how sfnt_get_name_index() does a linear search through the font to find a matching name. Much better if LilyPond could look up text characters by their Unicode encoding. Well, there are historic reasons for that. On the other hand, I think that for lilypond, which often provides multiple glyph representation forms of certain elements, glyph names are a better choice. The linear search in `sfnt_get_name_index' could be easily improved by providing a sorted array, replacing the linear search with binary search. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Fri, Dec 13, 2013 at 10:02:23AM -0500, Carl Peterson wrote: On Thu, Dec 12, 2013 at 7:36 PM, carl.d.soren...@gmail.com wrote: I think that the index sidebar colors are too dark. They dominate the page, in my opinon. In the current design, the sidebar color and the highlight box fill color are the same. Why not keep it that way? Attaching another option, to address your concern, as well as Graham's. Yes, much better! Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Download: Add introductory text (issue 40510046)
https://codereview.appspot.com/40510046/diff/40001/Documentation/web/download.itexi
File Documentation/web/download.itexi (left):
https://codereview.appspot.com/40510046/diff/40001/Documentation/web/download.itexi#oldcode35
Documentation/web/download.itexi:35: @warningTextBased
Umm, isn't the whole point of this to be a warning? Why are you
removing the warning CSS tag?
https://codereview.appspot.com/40510046/diff/40001/Documentation/web/download.itexi
File Documentation/web/download.itexi (right):
https://codereview.appspot.com/40510046/diff/40001/Documentation/web/download.itexi#newcode42
Documentation/web/download.itexi:42: LilyPond is a @strong{command line
application} translating
That's very chatty. Did all the people complaining about this fail to
notice the existing warning?
Perhaps the CSS for the warning box should be light red, instead of
adding more text. I mean, if people didn't read the existing text, then
adding more is unlikely to help.
https://codereview.appspot.com/40510046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
On Thu, Dec 12, 2013 at 02:06:38PM +0100, Urs Liska wrote: The page GSoC 2012 is obviously outdated. What should be done with it? I suggest deleting it. There's no evidence that the proposed mentors are still available or interested, and those specific proposals are a small subject of the available issues in the tracker. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: Manual-Web
On Thu, Dec 12, 2013 at 09:34:28PM +0100, Urs Liska wrote: When I go there I can download the whole website as a PDF. OK, this makes sense. Getting it as one big HTML page also makes sense. [but where can I get it in info format?) We don't provide links to the info documents, because IMO none of them have any images built-in. info+images only happens through a proper make install, so that's not something we can offer on the website. But clicking on Web (split HTML) brings you to a copy of the whole website, just several directories below the original. I suppose we could hide that part in an @ifnothtml. If this page is there for the first two items I mentioned the text in the left box should definitely be clarified. Currently this manual leads the reader to believe that he gets yet one more manual, with some general information. I wouldn't object to having a few sentences added to that box. And there is one more thing I stumbled over (although I don't find an instance of it right now): There are links from within the real manuals that seem to link to the website but actually point to that web manual (i.e. pages below lilypond.org/doc/2.17/web). Unavoidable without a great deal of knowledge about the doc build system and quite possibly GUB as well. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: Manual-Web
On Fri, Dec 13, 2013 at 03:40:03PM -, Phil Holmes wrote:
I _think_ the odd place of web in the manuals hierarchy is down to
it being the only part of the documentation that built using make
website - it has something of a split personality between being
part of the documentation and the website.
No, there's three separate issues here.
- lilypond.org/web/ : the old website
- lilypond.org/website/ : the thing built with make website,
with an .htaccess to make /website/foo.html appear as /foo.html
- the documentation, which includes web.texi, and thus appears as
lilypond.org/doc/v2.17/website/ (I think, didn't check that url)
If we don't build web.texi within a normal doc build, then various
@ref{}s would fail, and the pdf-only and info-only docs would have
broken links. Also, come to think of it, a local installation of
the html files would also have broken links.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On Fri, Dec 13, 2013 at 10:41 PM, Graham Percival gra...@percival-music.ca wrote: On Fri, Dec 13, 2013 at 10:02:23AM -0500, Carl Peterson wrote: On Thu, Dec 12, 2013 at 7:36 PM, carl.d.soren...@gmail.com wrote: I think that the index sidebar colors are too dark. They dominate the page, in my opinon. In the current design, the sidebar color and the highlight box fill color are the same. Why not keep it that way? Attaching another option, to address your concern, as well as Graham's. Yes, much better! I have updated the patch in Rietvald (https://codereview.appspot.com/36480048/), per the images previously sent, with the exception that I slightly desaturated the colors to further reduce the cartoonish effect. Cheers, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Dec 13, 2013, at 9:07 AM, Keith OHara k-ohara5...@oco.net wrote: Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). Inserting print statements to trace those calls I find that FT_Get_Name_Index is called: 7 times for each character in a Tempo The layers of functions that result in repeated calls to the skylining code have changed since the original skylines patch. The latest change was author David Kastrup d...@gnu.org Thu, 21 Feb 2013 19:02:48 + (20:02 +0100) Issue 3200: Make ly:make-unpure-pure-container accept a single callback Like with fixed values, this gets duplicated for the pure value as well, but converted into a callback taking two more arguments (which are ignored). This type of unpure-pure-container is not a container of two functions but rather a single callback function, that promises to refrain from forcing line-break decisions (to be 'pure') and that ignores the two arguments giving the start- and end- of the line it would be on in the tentative line-breaks under consideration. In this case repeated calls will recompute the same value, so I see no reason to keep the function-call pointer in place after the first use. So I suggest we treat this case as if it were a simple lookup of a property, rather than a 'pure' lookup. http://codereview.appspot.com/42190043 This case includes the function to find skylines for Lyrics and TextScripts. On Thu, 12 Dec 2013 23:45:45 -0800, Mike Solomon m...@mikesolomon.org wrote: My LilyPond is not working for some reason (see previous e-mail about debugging). Once I get it up and running, I’ll have a go at this. Could you look at issue 3512 first ? If we get clear on what unpure-pure is all about we might be able to simplify things. For example, it seems to me that the unpure-pure-container with a single callback is not logically connected to any other unpure-pure-containers, so should have its own tag and different behavior. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
On 14/12/13 05:57, Carl Peterson wrote: On Fri, Dec 13, 2013 at 10:41 PM, Graham Percival gra...@percival-music.ca wrote: On Fri, Dec 13, 2013 at 10:02:23AM -0500, Carl Peterson wrote: On Thu, Dec 12, 2013 at 7:36 PM, carl.d.soren...@gmail.com wrote: I think that the index sidebar colors are too dark. They dominate the page, in my opinon. In the current design, the sidebar color and the highlight box fill color are the same. Why not keep it that way? Attaching another option, to address your concern, as well as Graham's. Yes, much better! I have updated the patch in Rietvald But not the tracker. So the patch will not get tested. Please remember to either use git-cl or change the tracker to patch-new whenever you make a change in Rietveld, we need to make sure that and new patch doesn't break anything in current master no matter how innocuous you think the changes are. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Keith OHara k-ohara5...@oco.net writes: On Dec 13, 2013, at 9:07 AM, Keith OHara k-ohara5...@oco.net wrote: Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). Inserting print statements to trace those calls I find that FT_Get_Name_Index is called: 7 times for each character in a Tempo The layers of functions that result in repeated calls to the skylining code have changed since the original skylines patch. The latest change was authorDavid Kastrup d...@gnu.org Thu, 21 Feb 2013 19:02:48 + (20:02 +0100) Issue 3200: Make ly:make-unpure-pure-container accept a single callback Like with fixed values, this gets duplicated for the pure value as well, but converted into a callback taking two more arguments (which are ignored). That was only creating a less awkward API for stuff that was already being done at a number of places. This patch should not have made a performance difference in itself. It might have encouraged and/or legitimized performance hogs. This type of unpure-pure-container is not a container of two functions but rather a single callback function, that promises to refrain from forcing line-break decisions (to be 'pure') and that ignores the two arguments giving the start- and end- of the line it would be on in the tentative line-breaks under consideration. In this case repeated calls will recompute the same value, The point of this would appear to be that the calculation tracks the changing placement of other elements depending on line-break decisions: there would be no point in using an unpure/pure container in the first place over a straight callback otherwise. so I see no reason to keep the function-call pointer in place after the first use. So I suggest we treat this case as if it were a simple lookup of a property, rather than a 'pure' lookup. http://codereview.appspot.com/42190043 That does not make sense. If you want call-once behavior, you can just use a callback. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Am 14.12.2013 04:53, schrieb Graham Percival: On Thu, Dec 12, 2013 at 02:06:38PM +0100, Urs Liska wrote: The page GSoC 2012 is obviously outdated. What should be done with it? I suggest deleting it. There's no evidence that the proposed mentors are still available or interested, and those specific proposals are a small subject of the available issues in the tracker. - Graham I assume that all infos about project examples are present on the tracker? So we wouldn't lose information through deleting it (apart from it being in the Git history of course) Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Fri, 13 Dec 2013 23:05:49 -0800, David Kastrup d...@gnu.org wrote: That does not make sense. If you want call-once behavior, you can just use a callback. At the moment, the decision on whether to preserve the callback pointer in the grob property, or fill the property with the returned value, depends on the method used to request the property, get_pure_property() versus get_property(). A callback would be called multiple times (and it would have to support the unpure-pure calling convention). The information of whether the callback is providing a value that /should/ be kept as final is better stored in the Grob itself, so I am thinking of ways to reorganize. The way stencil callbacks are evaluated now is interesting. The stencil callback itself is a simple callback, but when the layout engine wants to know the size of a stencil it does get_pure_property(Y-extent). Y-extent property is set to either execute the stencil callback, or estimate a height without building the final stencil, as appropriate for each Grob. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
On 14/12/13 07:14, Urs Liska wrote: Am 14.12.2013 04:53, schrieb Graham Percival: On Thu, Dec 12, 2013 at 02:06:38PM +0100, Urs Liska wrote: The page GSoC 2012 is obviously outdated. What should be done with it? I suggest deleting it. There's no evidence that the proposed mentors are still available or interested, and those specific proposals are a small subject of the available issues in the tracker. - Graham I assume that all infos about project examples are present on the tracker? http://code.google.com/p/lilypond/issues/list?can=1q=gsoc ? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
