> 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
>> 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'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
>> 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
>> 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
>> 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.
>
>
> 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
> 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
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
>>> 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
>>>
>>> ?
>>
>>> 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.
> 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
>> 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
>> 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
> 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
> 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
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.
>> 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
> 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
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
>>> 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 ‡
>> 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 *, †, ‡, §
>>
> 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
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
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
> 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 embed any text fonts
&g
>> 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
> 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
>> 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?
>
>
> 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
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
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
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
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
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
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
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 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 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
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 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
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:
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
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
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 truer...@trueroad.jp
Date: Tue, 14
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/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
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
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
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.
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
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
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
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
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
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
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.
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
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
.
- 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
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
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
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
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
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,
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
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
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:
101 - 200 of 226 matches
Mail list logo
