Hi.
Japanese resource (menu, dialog, etc.) of
official pre-built lilypad.exe is broken.
I installed lilypond-2.19.13-1.mingw.exe
(download from
http://download.linuxaudio.org/lilypond/binaries/mingw/lilypond-2.19.13-1.mi
ngw.exe)
and started lilypad.exe.
Then, all the Japanese character strings
- Original Message -
From: Phil Holmes m...@philholmes.net
To: lilypond-devel@gnu.org; Masamichi Hosoda
truer...@sea.plala.or.jp
Sent: Friday, September 05, 2014 1:19 PM
Subject: Re: lilypad.exe Japanese resource (menu, dialog, etc.)
- Original Message -
From: Masamichi
Message-ID: 40A388970C6540E08618DFC1C4932F1E@Advent
Now with the attachment :-(
--
Phil Holmes
- Original Message -
From: Phil Holmes m...@philholmes.net
To: lilypond-devel@gnu.org; Masamichi Hosoda
truer...@sea.plala.or.jp
Sent: Friday, September 05, 2014 1:19 PM
Subject: Re
it.
It is better to run make clean, before building lilypad.exe.
Otherwise, ANSI version objects may be mixed to UNICODE version lilypad.exe.
From: Masamichi HOSODA truer...@sea.plala.or.jp
Subject Re: lilypad.exe Japanese resource (menu, dialog, etc.)
Date Fri, 05 Sep 2014 22:45:42 +0900 (JST
I am interested in lilypad (Windows) development.
Thank you for merging my pull requests.
I've updated the CG with what I believe are the correct steps for
developments to LilyPad. The new text is in master, but not yet on the
website. I'd be interested in comments from anyone with
I'm trying to update GCC on GUB and have a new virtual machine with
updated versions. I was having problems getting MPFR to build, but it
looks like I'ev fixed that with the new VM. However, it looks to me like
GCC 4.8.2 has a new dependency on MPC that older versions did not: there
- Original Message -
From: Masamichi HOSODA truer...@sea.plala.or.jp
To: lilypond-devel@gnu.org
Sent: Thursday, October 23, 2014 12:07 PM
Subject: Re: GUB and mpfr/mpc
I'm trying to update GCC on GUB and have a new virtual machine with
updated versions. I was having problems
- Original Message -
From: Masamichi HOSODA truer...@sea.plala.or.jp
To: m...@philholmes.net
Cc: lilypond-devel@gnu.org; truer...@sea.plala.or.jp
Sent: Saturday, October 25, 2014 2:58 PM
Subject: Re: GUB and mpfr/mpc
- Original Message -
From: Masamichi HOSODA truer
How about this patch?
--- librestrict/xstatconv.c.org 2014-10-19 09:52:52.951262300 +0900
+++ librestrict/xstatconv.c 2014-11-01 20:26:35.734854500 +0900
@@ -48,20 +48,16 @@
{
struct stat *buf = ubuf;
+ /* zero clear */
+ memset(buf, 0, sizeof(*buf));
/*
Masamichi HOSODA truer...@sea.plala.or.jp writes:
How about this patch?
--- librestrict/xstatconv.c.org 2014-10-19 09:52:52.951262300 +0900
+++ librestrict/xstatconv.c 2014-11-01 20:26:35.734854500 +0900
@@ -48,20 +48,16 @@
{
struct stat *buf = ubuf;
+/* zero
I've succeeded to build lilypond for the following targets by gcc-4.8.2.
linux-x86
linux-64
freebsd-x86
freebsd-64
mingw
(I don't build lilypond for darwin environments because I don't have them.)
My building environment is Ubuntu 14.04 LTS 64 bit.
I use the following gub repository.
Masamichi HOSODA truer...@sea.plala.or.jp writes:
In mingw, lilypond crashes as follows.
Does someone know this reason?
```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bintype test.ly
{ c d e f g a b }
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\binlilypond test.ly
GNU LilyPond
Masamichi HOSODA truer...@sea.plala.or.jp writes:
Masamichi HOSODA truer...@sea.plala.or.jp writes:
In mingw, lilypond crashes as follows.
Does someone know this reason?
```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bintype test.ly
{ c d e f g a b }
C:\tmp\lilypond-2.19.16-0
Masamichi HOSODA truer...@sea.plala.or.jp writes:
Masamichi HOSODA truer...@sea.plala.or.jp writes:
In mingw, lilypond crashes as follows.
Does someone know this reason?
```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bintype test.ly
{ c d e f g a b }
C:\tmp\lilypond-2.19.16-0
I changed mingw.org's mingw-runtime to mingw-64 (32-bit).
Then an error didn't occur and correct test.pdf was generated.
https://github.com/trueroad/gub/tree/binutils-2.24
I may pull request if you request it.
Further, even if the runtime is mingw-w64,
bad_alloc occurred when
,
the result was that correct PDF was generated.
The source tree when succeeding, is as follows.
https://github.com/trueroad/gub/commit/5e63dbde436bd3fca154557672394987c8d2e385
Masamichi Hosoda
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
I changed mingw.org's mingw-runtime to mingw-64 (32-bit).
Then an error didn't occur and correct test.pdf was generated.
https://github.com/trueroad/gub/tree/binutils-2.24
I may pull request if you request it.
Further, even if the runtime is mingw-w64,
bad_alloc occurred when
I changed mingw.org's mingw-runtime to mingw-64 (32-bit).
Then an error didn't occur and correct test.pdf was generated.
https://github.com/trueroad/gub/tree/binutils-2.24
I may pull request if you request it.
Further, even if the runtime is mingw-w64,
bad_alloc occurred when
There is this at the end of skyline.cc:
// Should add during ver2.19 (to avoid an endless loop
// when merging identical skylines with a vertical segment)
// if (end = s2-front().end_) s2-pop_front();
I meant at the end of internal_merge_skyline() in skyline.cc. (Fatigue
I've seen a proposed patch from Masamichi, but as David says, this may
fix the issue but doesn't shed any light on what is the root cause.
Is it worth trying to go back to an earlier version of gcc? If so,
how would I go about that?
I lean towards just using Masamichi's patch.
I'll pull
I agree that changing the algorithms is preferred; I didn’t mean to suggest
otherwise. But if that’s not going to happen overnight, and there is a way
to mitigate the problem in the meantime without touching the code, the people
affected would value it.
I tried -mfpmath=sse -msse2.
It
Converting to `./test.pdf'...
warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE
-dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=./test.pdf
-c.setpdfwrite -ftest.ps)' failed (139)
fatal error: failed files: test.ly
When environment variable PATH is undefined, the following error occurs.
```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\binset PATH=
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\binlilypond
GNU LilyPond 2.19.16
terminate called after throwing an instance of 'std::logic_error'
what():
How does the upgrade to gcc 4.8.2 look now ?
Just wondering: There is already a gcc 4.9.x series, so why are we
trying to update to 4.8.x?
In this branch, I've tried gcc-4.9.
https://github.com/trueroad/gub/tree/gcc-4.9
I've succeed to build lilypond-installer
for mingw, linux-x86,
The changes from Masamichi to librestrict look safe,
and the later floating-point-endless-loop-eating-all-memory should be
gone now that I've re-worked the skyline merge code.
If gcc 4.8.2 still looks difficult, I'll look into problem with the
templates.
Now, in this branch,
The principle with GUB is that it has details of all the packages it uses,
and by issuing the 'make bootstrap' command, it goes and gets all the
packages it needs, and all their dependencies, and builds them all from
scratch. The problem I believe I now have is that gcc 4.8 has a new
I've succeed to upgrade GUB's ghostscript to 9.15 in this branch.
https://github.com/trueroad/gub/tree/ghostscript-9.15
I've succeed GUB's ``make lilypond'' by ghostscript-9.15.
All lilypond installers have been build.
In mingw (Windows):
Ghostscript can handle unicode filenames.
I've tested
Thank you for the mail.
I've written reply to the tracker web page.
https://code.google.com/p/lilypond/issues/detail?id=4317
Reviewers: ,
Message:
Pasting update in Tracker by David K for Masamichi's benefit:
--snip--
by d...@gnu.org: Patch: Add support for unicode filenames on
the unicode filenames.
From bb3f8bd6bcaf41de57e8981ac57a3ac0ef8c Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda truer...@trueroad.jp
Date: Sat, 7 Mar 2015 18:42:57 +0900
Subject: [PATCH] Add unicode filename support for Windows
---
flower/include/mingw-utf8-conv.hh | 7 ++
flower/include/mingw
linux-64: Ubuntu 14.04 LTS 64 bit
ligatured pdf is generated.
linux-x86: Ubuntu 14.04 LTS 32 bit (minimal install, no GUI, console only)
non-ligatured pdf is generated.
Ah, this is surprising, since up to now exactly the opposite behaviour
was reported (this is, working on
On 2015年3月29日 22:25:13 JST, Phil Holmes m...@philholmes.net wrote:
- Original Message -
From: Masamichi HOSODA truer...@trueroad.jp
To: m...@philholmes.net
Cc: lilypond-devel@gnu.org
Any advice anyone?
Would you show me the whole ghostscript.log and
/home/gub/NewGub/gub/target/darwin
Any advice anyone?
Would you show me the whole ghostscript.log and
/home/gub/NewGub/gub/target/darwin-ppc/build/soobj/arch.h ?
Attached.
Thank you.
It seems 32 bit hosts cross compiling issue.
I've updated the branch.
I have pulled Masamichi Hosoda's new pango-1.28 branch from his github
repository and the GUB build has failed building Ghostscript. I get the
following:
building package: darwin-ppc::ghostscript
*** Stage: download (ghostscript, darwin-ppc)
*** Stage: untar (ghostscript, darwin-ppc)
For this issue, I've written a patch to set the Helvetica substitute
and Courier substitute as the default font of provisional. [...]
Nice! Please upload your code to Rietveld following our contributors'
guide so that your changes can be tested automatically.
I've tried it.
How about
Have you checked ligatures? I think we were able to correlate our
ligature problems (don't know the issue right now) to the use of 64bit
architecture. It may be related to GhostScript.
I haven't.
Is it here?
http://code.google.com/p/lilypond/issues/detail?id=2656
I'll check it.
Have you checked ligatures? I think we were able to correlate our
ligature problems (don't know the issue right now) to the use of 64bit
architecture. It may be related to GhostScript.
I haven't.
Is it here?
http://code.google.com/p/lilypond/issues/detail?id=2656
I'll check it.
Yes,
Upload is now proceeding. Takes about 5 hours and slows internet
access for the house to a crawl :-(
Thank you for uploading official binaries.
I've tested the binaries in my environments.
The results are as follows.
linux-x86: Ubuntu 14.04 LTS x86_64 (with 32bit libs)
Fine
linux-64:
On Mar 2, 2015, at 09:03 , Masamichi HOSODA truer...@sea.plala.or.jp wrote:
darwin-x86:
Untested
My Intel Mac environment was quite a temporary.
Now, I don't have it.
It runs without crashing on 10.10.2.
Thank you for reporting.
I'm happy to hear
I still suspect a Pango bug that has probably been fixed in the not
too distant past. What version are you using? Can you upgrade to the
most recent one? On my 32bit GNU/Linux I use a quite recent git
version of Pango, which should behave identically to the last release
(1.36.8), and
So that’s probably a matter of the font, not of its style - not every font
defines ligatures, and the name „TakaoPGothic“ tells me its main focus would
be Japanese (is this true?), so the designers probably didn’t put so much
work in features of Latin script.
Would you care to try a
So that’s probably a matter of the font, not of its style - not every font
defines ligatures, and the name „TakaoPGothic“ tells me its main focus would
be Japanese (is this true?), so the designers probably didn’t put so much
work in features of Latin script.
Would you care to try a
I've succeed GUB's ``make lilypond'' by pango-1.28.3 in this branch.
https://github.com/trueroad/gub/tree/pango-1.28
I've checked again.
I've installed DejaVuSans to all environments.
linux-64 binary on Ubuntu 14.04 LTS 64 bit:
linux-x86 binary on Ubuntu 14.04 LTS 64 bit:
linux-x86 binary
.
- thinking about choosing default fonts for sans-serif and monospace
This patch should be rewritten in accordance
with the conclusions of the font choosing.
From 66a27d465cc2cf30929a6acf6e3c61ec3a41b5e1 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda truer...@trueroad.jp
Date: Sat, 28 Mar 2015 01:37:58
Converting to
`/cygdrive/e/cyg_pub/devel/lilypond/lilypond-2.18.2-1.x86_64/build/build/out/lybook-db/54/lily-487dce2c.pdf'...
Converting to PNG...
fatal error: GS exited with status: 256
Patch counted down - please push
https://codereview.appspot.com/227850044/
I don't have git account.
I've attached the patch file to this mail.
Would you push it?
From 9a4757685fa0e877cc1e970915376de8a550a569 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda truer...@trueroad.jp
Date: Wed, 15
I presume this is owing to the changes to font handling that Masamichi has
made, and I also presume that I can fix this by updating GUB. Problem is,
I'm confused with how to go about the latter. My current GUB build
environment is cloned from https://github.com/trueroad/gub and is built from
Patch counted down - please push
https://codereview.appspot.com/232850043/
I don't have git account.
I've attached the patch file to this mail.
Would you push it?
From aab1bada37a741025f0710842702da3eed0cf027 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda truer...@trueroad.jp
Date: Tue, 14
However, doing git grep TMP I also find
scripts/lilypond-invoke-editor.scm:(or
(getenv TMP)
which is from
(or (getenv TMP)
(getenv TEMP)
what happens if I set delete-intermediate-file to ##f?
Will the temporary PS file be renamed or copied to 'name.ps'?
No.
Temporary PS file will be created in the temporary directory,
instead of current directory.
If you set delete-intermediate-file to ##f,
lilypond will not delete the
The bug would be fixed if lilypond would make ghostscript use a
complete path to the intermediate lines.ps file for the ps to pdf
conversion.
Does anyone know how to convert from any path (relative and absolute
path)
to absolute path in scheme (guile) ?
Maybe the functions in this file
I think.
I've attached the renaming makefiles TMP variables patch to this mail.
From aab1bada37a741025f0710842702da3eed0cf027 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda truer...@trueroad.jp
Date: Tue, 14 Apr 2015 23:36:35 +0900
Subject: [PATCH] Rename makefile variable TMP
Windows (cygwin
cygwin-python.patch:
Set LDFLAGS to build python module
cygwin-remove-pathconv.patch:
Remove cygwin_conv_to_posix_path
This patch is similar to yours.
Don't know enough about Cygwin to know whether those two are the right
thing. I'd recommend passing them through review
cygwin-python.patch:
Set LDFLAGS to build python module
cygwin-remove-pathconv.patch:
Remove cygwin_conv_to_posix_path
This patch is similar to yours.
Don't know enough about Cygwin to know whether those two are the right
thing. I'd recommend passing them through review
64 bit make doc on 2.19.18 was completed.
on 32 bit I have still issue but much later for a different issue.
Any idea what could cause python to segfault here
or how to debug it ?
Do you use 64 bit Windows?
About two years ago, I installed cygwin (32 bit) to 64 bit Windows.
It was buggy.
Attached the patches I am using, to remove the
dos_to_posix CYGWIN specific usage.
Not clear why it was needed in the past, it is not needed
in a pure cygwin enviroment and cygwin_conv_to_posix_path
is deprecated on 32bit and not available on 64bit.
I've used three patches to build
I am using an equivalent way on the build system
make LDFLAGS=$(python-config --libs)
Thank you.
When GUB builds cygwin and mingw lilypond,
it seems to be using a similar way.
However, when GUB builds linux lilypond etc., the option is not used.
It is not cleary for me that why the option is
On 4/11/2015 2:08 PM, Masamichi HOSODA wrote:
Installed contains the results of running the program
after installation only on that snippets.
As it works, I am very puzzled.
$ lilypond --png lily-487dce2c.ly
GNU LilyPond 2.18.2
Processing `lily-487dce2c.ly'
Parsing...
Renaming input
Installed contains the results of running the program
after installation only on that snippets.
As it works, I am very puzzled.
$ lilypond --png lily-487dce2c.ly
GNU LilyPond 2.18.2
Processing `lily-487dce2c.ly'
Parsing...
Renaming input to: `out-www/quantize-start-midi.ly'
Interpreting
cygwin-env-TMP.patch:
Don't use environment variable TMP when make doc
If I understand correctly,
cygwin system use environment variable TMP for a special purpose.
In other words, on cygwin,
it can not be used for other purpose like Makefile variable.
That one is
So, I use cygwin64 on 64 bit Windows.
Has current 32 bit cygwin been fixed the such problem?
There was some improvement, specially as automatic rebase after
install
is now in place. But they are always possible.
https://cygwin.com/faq.html#faq.using.fixing-fork-failures
Anyway, I can
Your yes. But It is not my problem.
On my 32 bit I have a segfault of the python interpreter, much
later on
How about this?
$ export PYTHONDEBUG=1
$ make doc
or
$ export PYTHONVERBOSE=1
$ make doc
have you looked at the output of rebase -si ?
Yes.
There is no collisions.
$ rebase -si |
Patch counted down - please push
https://codereview.appspot.com/224800043/
I don't have git account.
I've attached the patch file to this mail.
Would you push it?
From d220ccbd436f050418eee28c9841309ab3925cfd Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda truer...@trueroad.jp
Date: Wed, 8
I'll integrate the font directory specified options.
For example,
from --with-ncsb-dir, --with-helv-dir, --with-cour-dir
to --with-fonts-dir
I've done.
Patch Set 2 has been uploaded.
https://codereview.appspot.com/224800043/
http://code.google.com/p/lilypond/issues/detail?id=4332
Hello,
Here is the current patch countdown list. The next countdown will be
on June 11th.
You can always view the most current countdown list here:
the fontconfig allows for a
fallback fonts anyway. It's not a big deal. I was just curious. Looks like
Masamichi Hosoda made these changes.
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=28f58ecc2271956e9377dc61e5135ce3ade4abbd
Thanks for everything you all do to make this program
I've uploaded the following patch to Rietveld.
Define default fonts in fontconfig configuration file
This commit defines LilyPond default fonts
in local fontconfig configuration file.
And, LilyPond uses them.
It is possible to combine multiple fonts
with different character
COUNTDOWN:
...
Masamichi Hosada: Patch: Add MinGW support of
scale-down-image (ps-to-png.scm)
http://code.google.com/p/lilypond/issues/detail?id=4431
Is this count down? push?
Its on countdown. That means that unless anything is requested
before June 17th, you can push it
COUNTDOWN:
...
Masamichi Hosada: Patch: Add MinGW support of scale-down-image
(ps-to-png.scm)
http://code.google.com/p/lilypond/issues/detail?id=4431
Is this count down? push?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
COUNTDOWN:
...
Masamichi Hosada: Patch: Add MinGW support of scale-down-image
(ps-to-png.scm)
http://code.google.com/p/lilypond/issues/detail?id=4431
Is this count down? push?
Its on countdown. That means that unless anything is requested before
June 17th, you can push it
I've uploaded the patch
`Add MinGW support of scale-down-image (ps-to-png.scm) '.
http://code.google.com/p/lilypond/issues/detail?id=4431
https://codereview.appspot.com/241980043
This can handle like following command on MinGW.
lilypond --png -danti-alias-factor=4 foobar.ly
Dear Phil,
Thanks. I’m aware that without passing you the score this will possibly never
get fixed. My issue occurs on Fedora 21, 22 and Mint 17, which is Ubuntu
based. At this point, I am going to try a binary chop debugging approach. I
had hoped the previous posting of the failed
following mail's issue.
This patch makes easy to analyse it.
From: Masamichi HOSODA truer...@sea.plala.or.jp
Subject Re: cygwin64 - building 2.18.2 doc fails
Date Mon, 13 Apr 2015 23:29:38 +0900 (JST)
lilypond-2.18.2's ``input/regression/midi/GNUmakefile'' (without my patch)
uses TMP
If you use Debian or Ubuntu etc., please install `fonts-texgyre' package
like following command before compiling LilyPond.
$ sudo apt-get install fonts-texgyre
Didn’t work in LilyDev 3:
What worked for me was this:
1. Edit /etc/apt/sources.list to refer to ftp.ca.debian.org instead
On 21/08/15 19:05, Dan Eble wrote:
If you use Debian or Ubuntu etc., please install `fonts-texgyre' package
like following command before compiling LilyPond.
$ sudo apt-get install fonts-texgyre
Didn’t work in LilyDev 3:
What worked for me was this:
1. Edit /etc/apt/sources.list to refer
find isinf, and possibly this patch is
guilty:
http://code.google.com/p/lilypond/issues/detail?id=4550
I've reproduced it on my Cygwin64 gcc-4.9.3 environment.
Attached patch can be fixed it.
From 5d4af6d8ad286dce49e65af14f8c008f59dd36d5 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda truer
Following the changes to the fonts, I'm now having GUB fail. The log shows:
configure: WARNING: unrecognized options: --enable-shared, --disable-static,
--disable-silent-rules, --with-fonts-dir
WARNING: Please consider installing optional programs or files: dblatex
ERROR: Please
I'm going to push Issue 4552: Change the LilyPond default fonts to TeX Gyre
https://code.google.com/p/lilypond/issues/detail?id=4552
This changes LilyPond default fonts from URW++ to TeX Gyre.
Along with it, this also changes a configure option.
If you compile LilyPond, please read following.
hi,
this patch fixes the issue. fontforge is now detected and configure
script finishes without issue.
thanks.
Dne 22.8.2015 v 14:25 Masamichi HOSODA napsal(a):
i attempted to install lilypond- gentoo ebuild but it fails because it
does not detect fontforge version correctly
I've noticed an issue of Japanese serif font selection on Windows.
If you specify a serif (roman), sans-serif font `MS Gothic'
is used for Japanese glyphs.
One of the causes is fontconfig-2.8.0's `Bug 43406'.
https://bugs.freedesktop.org/show_bug.cgi?id=43406
So I've sent a pull request `Update
I've noticed an issue of Japanese serif font selection on Windows.
If you specify a serif (roman), sans-serif font `MS Gothic'
is used for Japanese glyphs.
One of the causes is fontconfig-2.8.0's `Bug 43406'.
https://bugs.freedesktop.org/show_bug.cgi?id=43406
So I've sent a pull request
The Darwin-PPC compile now proceeds fine following the revert. I'm now
getting a failure to build the daja-vu fonts: it looks like the font file
has not been downloaded:
invoking tar -C /home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
--strip-component=1 -v -j -xf
The Darwin-PPC compile now proceeds fine following the revert. I'm
now
getting a failure to build the daja-vu fonts: it looks like the font
file
has not been downloaded:
invoking tar -C
/home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
--strip-component=1 -v -j -xf
The Darwin-PPC compile now proceeds fine following the revert. I'm
now
getting a failure to build the daja-vu fonts: it looks like the font
file
has not been downloaded:
invoking tar -C
/home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
--strip-component=1 -v -j -xf
Hello
On 28-08-2015 13:11, James wrote:
Hello,
On 28/08/15 09:13, Villum Sejersen wrote:
For around a week I have encountered a strange error message when
installing lilypond master from git sources. I have no local branches.
address@hidden:/usr/local/src/lilypond/build# lilypond -v
origin/master
$ rm -fr downloads/fonts-urw-core35/
> I've forwarded this to the bug list so someone should create a
> tracker.
>
> Please note the bug list is now at
> http://sourceforge.net/p/testlilyissues/issues/
>
> --
> Phil Holmes
>
>
> - Original
There's lots of differences, presumably down to font changes,
>>>
>>> Also sans \bold and \italic do not seem to work in font-family-override.ly
>>
>> And in kievan-notation.ly the spacing of the lyrics in-syllable is
>> awful. Whatever font we chose there has metrics that appear hardly
>>
>>>There's lots of differences, presumably down to font changes,
>>
>> Also sans \bold and \italic do not seem to work in
>> font-family-override.ly
>
> Well, I call uh-oh. It will probably take a few more unstable releases
> to shake out the problems from the font setup changes.
Probably, it
>>>There's lots of differences, presumably down to font changes,
>>
>> Also sans \bold and \italic do not seem to work in font-family-override.ly
>
> And in kievan-notation.ly the spacing of the lyrics in-syllable is
> awful. Whatever font we chose there has metrics that appear hardly
> suitable
> Hi,
>
> I newly nuked my \build-directory in order to get a fresh one.
>
> But I have some problems (being on LilyDev3):
>
> 1)
> ~/lilypond-git/build (master)$ ../configure
> returns:
> ERROR: Please install required programs: TeX Gyre fonts OTF (make
> sure the fc-list utility can see
> Hello,
>
> Doing a simple
>
> lilypond -dbackend=svg test.ly
>
> My SVG output appears to not be embedding the fonts.
>
> From the Application Usage Guide it states:
>
> "... This creates a single SVG file, without embedded fonts, for every
> page of output. It is recommended to install the
> Hosada-san
>
> On 13/09/15 23:00, Masamichi HOSODA wrote:
>>>> In my experiment, by LilyPond 2.19.22 (before changing fonts to TeX Gyre),
>>>> SVG output is not embeded text fonts.
>>>> So I think that SVG backend does not embed any text fonts
&g
>> In my experiment, by LilyPond 2.19.22 (before changing fonts to TeX Gyre),
>> SVG output is not embeded text fonts.
>> So I think that SVG backend does not embed any text fonts
>> independently of font changing to TeX Gyre.
>>
>
> Did you use the downloadable binary or from git directly?
>
>
>> Hosada-san
>>
>> On 13/09/15 23:00, Masamichi HOSODA wrote:
>>>>> In my experiment, by LilyPond 2.19.22 (before changing fonts to TeX Gyre),
>>>>> SVG output is not embeded text fonts.
>>>>> So I think that SVG backend does not e
>> To use LuaTeX, I've tried following command.
>>
>> $ PDFTEX=luatex PDFLATEX=lualatex make -j 16 CPU_COUNT=16 LANGS='' doc
>>
>> Then, it shows the following error.
>>
>> ```
>> ./18/lily-10433670.texidoc:3: Undefined control sequence.
>> l.3 ...on, which assigns the symbols *, †, ‡, §
>>
It seems that LuaTeX can not build LilyPond documents due to LuaTeX's bug.
http://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00055.html
Moreover, recent LuaTeX seems to have made significant changes
to the PDF-related function.
Perhaps, latest LuaTeX can not use current texinfo.tex.
On
> Until then, we might replace `§' and `¶' (the latter character also
> fails with luatex), with the commands `@S' and `@P', respectively.
> Patch appended.
I've noticed another problem.
By your patch, `@S' and `@P' are no problem.
† and ‡ occur no errors but they are missed in PDF.
Attached
My previous mail seems Japanese encoding.
So I re-send the mail in UTF-8.
> Until then, we might replace `§' and `¶' (the latter character also
> fails with luatex), with the commands `@S' and `@P', respectively.
> Patch appended.
I've noticed another problem.
By your patch, `@S' and `@P' are no
> It seems that LuaTeX can not build LilyPond documents due to LuaTeX's bug.
> http://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00055.html
>
> Moreover, recent LuaTeX seems to have made significant changes
> to the PDF-related function.
> Perhaps, latest LuaTeX can not use current
>>> By your patch, `@S' and `@P' are no problem. † and ‡ occur no
>>> errors but they are missed in PDF.
>
> Yes, there are more problems in texinfo.tex with non-8bit engines – it
> seems that the complete UTF-8 logic is severely broken in that case.
>
> For 8bit engines, the glyphs for † and ‡
> In the PDF version of the snippet above, the "fl" letters of "flag" are
> missing. I think this is probably because they are being converted to a
> ligatured glyph, and then not displaying. Anyone know how to prevent this
> from happening?
If I understand correctly, it is pdfTeX issue.
In
1 - 100 of 226 matches
Mail list logo
