> configure:3706: checking whether the C compiler works
> configure:3728: x86_64-freebsd6-gcc conftest.c >&5
> x86_64-freebsd6-gcc: internal compiler error: Illegal instruction (program
> cc1)
> librestrict:error:/home/gub/NewGub/gub/target/freebsd-64/root/usr/cross/bin/x86_64-freebsd6-gcc:
>
> The path in this line looks a bit wrong:
> cc1: error:
> /home/ralph/gub/target/tools/root/usr/lib/libffi-3.2.1/include: No
> such file or directory [-Werror=missing-include-dirs]
>
> Is nobody else having these issues?
In my GUB environment, it is warnings instead of errors.
Anyway, I've crea
>> You should get more debugging information in the terminal output -
>> it normally has something like "Tail of .log". Have a good look
>> in xxx.log and see what the error is.
>
> Irrespective of that, can someone please fix the `restrict' problem?
> It should be a trivial renaming issue.
I
> I've accepted the pull requests on GitHub and updated my system as
> above. I'm now getting a failure rebuilding Guile. I've attached the
> end of the logfile to avoid problems with line wrapping making the
> error messages unintelligible.
I've created pull request for fixing guile compilation.
>> Please use 5.x – 4.x is no longer supported.
>
> Or even better 6.x.
I've created pull request for updating texinfo to 6.1.
https://github.com/gperciva/gub/pull/25
In my GUB environment, the following commands are succeed.
$ bin/gub tools::texinfo
$ bin/gub linux-64::lilypond
$ bin/gub linux
>> For remote PDF links, rather than they are lost, I think that PDF
>> destination names are replaced.
>
> Hmm. This smells fishy.
>
>> Would you know a tool other than texinfo that can generate remote
>> PDF links?
>
> Sorry, no.
I've noticed that
plain pdfTeX (without texinfo) can generate
>> PDF outline is not lost. It is hidden. The following command can
>> let show it.
>>
>> $ gs -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=foo.new.pdf \
>> foo.pdf -c '[ /PageMode /UseOutlines /DOCVIEW pdfmark'
>
> What exactly do you mean with `hidden'? Are PDF viewers still capa
>> I think this is due to texinfo.tex bug.
>> This patch might fix it. [...]
I've created Issue 4940.
https://sourceforge.net/p/testlilyissues/issues/4940/
>> However, even if fix this, there are two problems.
>>
>> PDF outline is lost.
>> Remote PDF links (between PDFs) are lost.
>
> Interest
> Just for fun I tried to execute
>
> ps2pdf notation.pdf notation.pdf.new
>
> I got zillions of warnings
>
> Warning: Outline has invalid link that was discarded.
>
> and then zillions of
>
> Warning: Link annotation points out of the document page range.
>
> It closes with
> could you point me to the right direction for adding support for the atom
> text editor to the lilypond-invoke-editor script?
>
> The syntax of the command to invoke is simply 'atom file:line:column', e.g.
> atom text.ly:42:7
>
> This should be a very small addition to a single script (I'd assu
Phil,
>> make[1]: *** No rule to make target
>> `/home/gub/NewGub/gub/target/darwin-ppc/root/usr/include/freetype2/freetype/ftxf86.h',
>> needed by `out/pango-font.o'. Stop.
>> make[1]: *** Waiting for unfinished jobs
>
> Ouch. It seems that this is an old pango version that calls FreeTyp
>>> So do we need any warnings or notes to be added to here:
>>>
>>> http://lilypond.org/doc/v2.19/Documentation/usage-big-page#advanced-command-line-options-for-lilypond
>>>
>>> and/or here:
>>>
>>> http://lilypond.org/doc/v2.19/Documentation/notation-big-page#entire-document-fonts
>>>
>>> ?
>> In
>>> Any idea why this is so? Could you contact the gs people by filing
>>> a bug report so that we get an explanation?
>>
>> If I understand correctly, there is four issues at least. [...]
>
> Thanks for your analysis.
There is ghostscript developers reply.
http://bugs.ghostscript.com/show_bug
> So do we need any warnings or notes to be added to here:
>
> http://lilypond.org/doc/v2.19/Documentation/usage-big-page#advanced-command-line-options-for-lilypond
>
> and/or here:
>
> http://lilypond.org/doc/v2.19/Documentation/notation-big-page#entire-document-fonts
>
> ?
In my humble opini
>> I've tried some Japanese fonts with `-dgs-load-fonts' option. [...]
>>
>> So most Japanese fonts can not be used with `-dgs-load-fonts'
>> option.
>
> Any idea why this is so? Could you contact the gs people by filing a
> bug report so that we get an explanation?
If I understand correctly,
>>> In addition, all fonts of the above without `-dgs-load-fonts' option are
>>> fine.
>>> I suggest removing `-dgs-load-fonts' option from lilypond-book.
>>> I think that `--bigpdfs' option is more suitable than
>>> `-dgs-load-fonts'.
>>
>> Either make for particularly large PDF files, don't the
>> In addition, all fonts of the above without `-dgs-load-fonts' option are
>> fine.
>> I suggest removing `-dgs-load-fonts' option from lilypond-book.
>> I think that `--bigpdfs' option is more suitable than
>> `-dgs-load-fonts'.
>
> Either make for particularly large PDF files, don't they?
If
> As of
> http://www.mail-archive.com/bug-lilypond@gnu.org/msg40846.html
> I had uninstalled Noto and instead installed IPA fonts _and_ IPAex fonts.
> After uninstalling IPAex fonts - first the test-case worked and now I
> have success on a full `make doc'.
It seems that fonts-ipaexfont-{mincho|go
> In addition, the following command sequence succeeds:
>
> lilypond-book aaa-lilybook-test.lytex
> latex aaa-lilybook-test.tex
> dvips aaa-lilybook-test.dvi
> ps2pdf aaa-lilybook-test.ps
> evince aaa-lilybook-test.pdf
>
> aaa-lilybook-test.ps is >16MB again, though.
Thank you for your results.
> %%% start of aaa-lilybook.lytex
>
> \documentclass[a4paper]{article}
>
> \begin{document}
>
> \begin{lilypond}
> \markup {
> %foo bar buzz
> いろはにほへど ちりぬるを
> }
>
> \end{lilypond}
>
> \end{document}
>
> %%% end of aaa-lilybook.lytex
>
> always fails with:
>
> $ lilypond-book --o
> Is there anybody out there who succeeds to build the current lilypond
> documentation on a 64 bit linux machine with a 64 bit toolchain?
> Please report cpu as well as versions of gcc and guile.
Although my environment is not linux,
I've succeeded `make doc' by HEAD of master branch.
Of course,
>> I've opened a bug report to discuss whether ghostscript will add OTC
>> support, and whether the gs team is going to extend Type42 support
>> to cover generic SFNTs (i.e., CFF flavour also).
>>
>> http://bugs.ghostscript.com/show_bug.cgi?id=696808
>
> And there's a quick reply: No OTC suppor
If I understand correctly,
current LilyPond cannot handle OpenType/CFF Collection (OTC) fonts
(NotoSansCJK.ttc and SourceHanSans.ttc etc.).
LilyPond processes them as TrueType Collection (TTC) fonts,
and outputs wrong PostScript file.
I thought it was a Ghostscript's issue.
http://lists.gnu.org/ar
>> It seemed that this was because I had removed texlive-xetex - in order
>> to test that 'configure' showed the correct information and warned me
>> if I tried to run it without it installed.
>>
>> However I really struggled to get any kind of successful doc compile
>> even when I apt-get installe
> 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.
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 the
>>> 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 ‡
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
> 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 file
>> 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 *, †, ‡, §
>>
pdfTeX warning: pdfetex (file
/usr/share/texmf-dist/fonts/type1/public/tex-gyre
/qcsr.pfb): glyph `f_i' undefined
>>>
>>> Yep, the font in question only contains `fi' and `fl' glyph names.
>>
>> How could we fix this?
>
> We can't, except using luatex, as suggested by Masamichi-san
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 pd
> 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
>> 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
> 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?
>
>
> 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
> 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 them,
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
>> su
ter
$ git merge 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
>
>
>>>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
>>>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 ca
> 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/lilyp
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-com
>> 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 /home/gub/New
^
>
> It looks like the compiler cannot 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 5d4af6d8ad286dce49e65a
> 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: Pleas
> 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
>
> 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/a
>>> 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.d
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.
> 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 r
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 f
ers? It looks like 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
>
> Than
> 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
>>> 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 befo
> 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
https
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 s
> 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:
> http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaiting&colspec=Patch%20Owner%20ID%20Summary&
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
error
like following mail's issue.
This patch makes easy to analyse it.
From: Masamichi HOSODA
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)
&
> what happens if I set delete-intermediate-file to ##f?
> Will the temporary PS file be renamed or copied to '.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 temporary
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 f
> However, doing "git grep TMP" I also find
> scripts/lilypond-invoke-editor.scm:(or
> (getenv "TMP")
>
> which is from
>
>(or (getenv "TMP")
>(getenv "TEMP")
>
> 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
Date: Tue
> 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 f
> Patch counted down - please push
>
> https://codereview.appspot.com/227200043/
I don't have git account.
I've attached the patch file to this mail.
Would you push it?
>From e50938881680c6f673d6c66f1f9619d9b3abfc65 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda
Date: Wed
>>> The latter would need another similar fix. And the former uses
>>> Windows-only conventions: the POSIX convention is to look in the TMPDIR
>>> variable. So it might warrant putting a TMPDIR check in front.
>>>
>>> The TMPDIR patch should likely be separate (as it is a different issue
>>> and
> 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
Date: Wed
> 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
Date: We
> 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 -
>> 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
>
>
>
>> 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
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 recomm
>>> 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 passi
>>> 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.
fix. And the former uses
> Windows-only conventions: the POSIX convention is to look in the TMPDIR
> variable. So it might warrant putting a TMPDIR check in front.
>
> The TMPDIR patch should likely be separate (as it is a different issue
> and just discovered in parallel). But th
> 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
> 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 lilyp
> 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
>>
> 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'
> Int
>
> 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
> ---
> 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
___
>>> 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.
https://github.com/trueroad/gub/commit/27a90b6b8c6d2f2acb1062
On 2015年3月29日 22:25:13 JST, Phil Holmes wrote:
>- Original Message -
>From: "Masamichi HOSODA"
>To:
>Cc:
>>> Any advice anyone?
>>
>> Would you show me the whole ghostscript.log and
>> /home/gub/NewGub/gub/target/darwin-ppc/build/
> 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-p
>> 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 abou
onospace font.
> - 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
Date: Sat, 28 Mar 2015 01:
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 o
>> 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
> 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 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),
>> 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, w
>>> 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'l
> 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.
_
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 lily
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
later can treat the unicode filenames.
>From bb3f8bd6bcaf41de57e8981ac57a3ac0ef8c Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda
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/m
101 - 200 of 229 matches
Mail list logo
