Masamichi Hosoda [Thu, 16 Mar 2017 11:42:15 +0000 (20:42 +0900)]
Issue 5100: Prevent race condition in font export directory making
When a font export directory is necessary,
LilyPond tested the existence of the directory,
and if the directory did not exist, LilyPond made the directory.
However, LilyPond raised the error that the directory already exists
if another process made the directory between the testing and the making.
This commit prevents such race condition.
By deleting the existence test,
LilyPond always tries to make the directory regardless of existence.
Then suppress the error that the directory already exists.
Francisco Vila [Fri, 24 Mar 2017 18:48:48 +0000 (19:48 +0100)]
Web-es: version marker for Community.
This completes in theory a full update of Spanish web and
documentation. Next is texidocs (snippet documentation), which is a
huge task as there are 330 outdated files.
Previously both MultiMeasureRest and MultiMeasureRestNumber were
caused by the rest event itself, making tweaks always address either
object. Use a directed tweak to MultiMeasureRestNumber for reaching
it now.
David Kastrup [Tue, 14 Mar 2017 10:29:42 +0000 (11:29 +0100)]
Issue 5094: Change error message for unrecognized strings
Instead of mentioning the modes in which arbitrary strings would be
permissible, state that the string is not a note name. This is more
likely to be helpful to users, particularly in the case of wrong
notename language.
Masamichi Hosoda [Sat, 11 Mar 2017 10:12:15 +0000 (19:12 +0900)]
Issue 5077/2: Improve portability of get_working_directory()
We used `getcwd()` with `PATH_MAX` to get the current directory.
However, `PATH_MAX` does not exist in environments such as GNU Hurd.
Debian developers avoided `PATH_MAX`
by using `get_current_dir_name()` instead of `getcwd()`.
It needed to protected with `#ifdef _GNU_SOURCE`
since `get_current_dir_name()` is glibc specific.
So `PATH_MAX` was still required in non-glibc environments.
There is a `getcwd()` extention that can avoid `PATH_MAX`
by setting the first argument to NULL.
The extension can be used in many environments, including glibc,
but POSIX does not recommend it in conforming applications.
This commit improves portability
by obtaining the current directory
with a method conforming to the standard.
David Nalesnik [Sat, 4 Mar 2017 15:16:09 +0000 (09:16 -0600)]
Issue 5086: Fix dashed line errors
There are two errors in lily/line-interface.cc which cause
dashed lines to be drawn inaccurately.
(1) Line-thickness is improperly subtracted from the "off"
value in Line_interface::make_dashed_line. This was done,
presumably, to account for the line cap of each dash. In fact,
PostScript discounts the line cap when constructing the pattern.
(2) Dashed lines are constructed so that they begin and end
with a dash. Thus, a dashed line is built of dash + whitespace
units and a last lone dash. Period is not adjusted in
Line_interface::line for this last dash, which can lead to a
noticeable difference in its length compared to other dashes.
Correcting these flaws ensures that dashed lines end with a
dash rather than whitespace, and that terminating dashes are
not clipped. Also, the number of dashes drawn reflects the
number calculated.
Issue 5082/3: Add comment to build Japanese PDF documents
Building Japanese PDF documents requires
Japanese fonts and some packages.
Unfortunately, most developers do not have them.
Therefore, Japanese PDF is not built by default.
This commit adds a comment which describes the requirements
to build Japanese PDF documents
for the developer who wants to build them.
Issue 5082/1: Add Japanese texinfo.tex support files
Japanese PDF documents are not built
since texinfo.tex (until Texinfo 6.3)
and TeX engine (pdfTeX) do not support Japanese.
The new texinfo.tex (Texinfo 6.3+)
and the modern TeX engine (XeTeX and LuaTeX)
can handle Japanese PDF.
This commit adds Japanese texinfo.tex support files
from Texinfo SVN repository r7681.
They consist of the following two files.
texinfo-ja.tex
Japanese texinfo.tex loader
txi-ja.tex
Japanese translations and font definitions for texinfo.tex
David Nalesnik [Thu, 23 Feb 2017 15:57:44 +0000 (09:57 -0600)]
Issue 5084: Create Bracket class
Code involving brackets suffers from two confusing
organizational issues:
(1) Tuplet_bracket::make_bracket is used to create brackets
for a number of grobs: BassFigureBracket, HorizontalBracket,
OttavaBracket, PianoPedalBracket, VoltaBracket, along with
TupletBracket
(2) Methods belonging to Horizontal_bracket are used to draw
both horizonal brackets (HorizontalBracket) and vertical
brackets (BassFigureBracket)
To remedy this, a new Bracket class is created.
This new class contains the old Tuplet_bracket::make_bracket,
Horizontal_bracket::make_bracket, and
Horizontal_bracket::make_enclosing_bracket.
These methods have been renamed to clarify their purpose.
David Kastrup [Tue, 7 Mar 2017 17:47:30 +0000 (18:47 +0100)]
Issue 5087: Let extendersOverRests default to ##t
This was effectively unchangingly the case before issue 5053
fixed the respective code. However, the relation to actual
behavior seems so tenuous that it appears more prudent to
reenable this by default and only disable it again (if at all)
once the behavior corresponds better with name and documentation.
Knut Petersen [Sat, 4 Mar 2017 18:10:19 +0000 (18:10 +0000)]
LyricHyphen whiteout
Issue 5033
A proper outline whiteout
would be ideal, but it is
not currently implemented.
The current code fails
because you need a relatively
large whiteout area for a
small object.
A brute force fix is to increase
the number of iterations, but
the result would be a pdf with
a high percentage of whiteout code.
There is the case where a long
melisma produces a single hyphen
event that generates a lot of
hyphens that cross a number of
mensuration lines.
Rectangular or roundedbox whiteout
will produce gaps in all
mensuration lines crossed, even
if there is no collision.
David Kastrup [Tue, 28 Feb 2017 23:33:51 +0000 (00:33 +0100)]
Issue 5079/2: with-music-match: lists should match completely
Previously music properties that were matched to a list of wildcards
could contain fewer elements than the list they were matched to,
leading to an error when the wildcard variable was being assigned to.
Now the list lengths have to be matched exactly: a shorter pattern
than the actual list length of the matched property cannot match any
more.
Urs Liska [Tue, 21 Feb 2017 11:42:48 +0000 (12:42 +0100)]
5067: Add ly:version? and lexicographic-list-compare?
Squashed commits:
5067: Restrict ly:version? to number list
5067: version-list-compare? rename to lexicographic-list-compare?
5067: version-list-compare? typo
ly:version? and version-list-compare?
A lexicographic list comparison for arbitrary element types,
but with special treatment of trailing elements
(additional elements of the longer list are ignored, which is
typical for version comparisons such as LilyPond 2.19 is equal to 2.19.4)
Simplify lilypond-version operator and create new interface
Add lilypond version predicates/operators
This set of predicates/operators compares a given reference version
to the LilyPond version that is currently being executed.
This makes it possible to implement "version switches" to write
(library) code that is compatible over syntax changes.
projects / lilypond.git / log