> I can't tell you for sure either. It could be that the fork at
> https://gitlab.com/trueroad/lilypond has Pipelines enabled, but only
> visible to project members. Hosoda-san, could you check this in your
> project? The drop-down is at Settings > General > Visibility ... >
> Pipelines. I'm guess
> The very problem seems to be that the PDF snippets in 'lybook-db' are
> no longer created with `-dgs-never-embed-fonts=#t`.
It seems `-dgs-never-embed-fonts=#t` does not work in current LilyPond.
I've created merge request !218 that fixes it.
> your fix for gs works fine; the resulting PDFs are small again.
> Thanks a lot!
>
> BUT: They are not as small as previously. For example, with commit
> 21a20de3, the NR has 10 pages more and is now 8.3MByte (I've tested
> compilation with both gs 9.21 and 9.52) instead of 7.1MByte (with gs
> 9
>> From the same PostScript file, the new method generates a PDF of
>> 7081 bytes and the old method generates a PDF of 6423 bytes. The
>> new method is more than 10 % larger than the old method.
>
> Do you consider this a bug in gs or a feature?
>
>> From `old-to-new.diff`, it seems that the am
> Ghostscript seems to need `-sDEVICE=pdfwrite` to produce the PDF we expect.
>
> Is the device specifying way on the new method (without `-sDEVICE=pdfwrite`)
> documented by Ghostscript documents?
> If not, it is not a bug in my humble opinion.
I've found the documented way to specify Ghostscrip
>>> I've found the documented way to specify Ghostscript devices
>>> without `-sDEVICE=pdfwrite`. It is using the operator
>>> `selectdevice`.
>
> Thanks for investigating. The main question remains why gs produces
> suboptimal results without `selectdevice`.
`selectdevice` is defined in gs_ini
>> `selectdevice` does `setdevice` and then `.setdefaultscreen`.
>> If we use only `setdevice`, then `.setdefaultscreen` is not done.
>
> Aha. So should we just call .setdefaultscreen ourselves? (calling
> "[...] setdevice (pdfwrite) finddevice setdevice" is duplicate) Looks
> like it was introduc
> Testing with Frescobaldi would be appreciated, and also with special
> characters in file names. I tried to model this after the code
> Masamichi-san wrote in March, but I'm not sure I understand what it's
> really needed for?
`stat ()` in msvcrt.dll has a problem with some Unicode file names.
S
>> `stat ()` in msvcrt.dll has a problem with some Unicode file names.
>> So we use `_wstat ()` instead of `stat ()` if msvcrt.dll is used.
>> To use `_wstat ()`, we need a wide string,
>> so we use `MultiByteToWideChar ()` to convert it.
>
> Do you have an example of a file name that should not w
> Thanks for all the explanation, I think I'm slowly starting to
> understand the problem. I've tried to get short names with special
> characters, but failed so far (maybe you need a setting for this?).
> I'm giving up on this for now and will keep the code path with
> MoveFileExW unless you feel
>> Do you have an example of a file name that should not work? I now have
>> three versions from GUB (one with MoveFileExW; one without but with
>> wstat; and one without wstat) and all work correctly on a recent
>> Windows 10. Does that mean the issue is gone with a recent update?
>
> Might it be
> That was also my understanding, but "dir /x" already shows a short name
> of "D15A~1.LY" for "ä.ly". Maybe I'm doing something wrong? (not used
> Windows at that technical level for a few years now...)
Sorry, I have no idea because I'm not familiar with non-Japanese Windows.
At least in Japanese
> * Documentation/snippets/utf-8.ly:
>
> [for Japanese] → Source Han Serif
For Japanese fonts, I suggest HaranoAji.
It is the default Japanese font from TeX Live 2020.
https://www.ctan.org/pkg/haranoaji
>>> For Japanese fonts, I suggest HaranoAji.
>>> It is the default Japanese font from TeX Live 2020.
>>>
>>> https://www.ctan.org/pkg/haranoaji
>>
>> OK, thanks for the suggestion.
>
> After some thinking I'm not sure whether HaranoAji is the best
> solution. Given that both LilyPond and ghosts
> [lilypond dcd531b0f, gs 9.52]
>
> Processing the following sample code
>
> \paper {
> #(define fonts
> (set-global-fonts
>#:roman "Source Han Serif TW"
>#:sans "sans-serif"
>#:typewriter "monospace"
> ))
> }
>
> \markup { "ろ" } % This is character
>> ```
>> Layout output to `./1a/lily-d0aeef0b.eps'...
>> fatal error: Font NotoSansCJKjp-Regular cannot be loaded via Ghostscript
>> because it is an OpenType/CFF Collection (OTC) font.
>> ```
> /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans CJK
> JP:style=Regular
This file
> Note: NotoSansJP-Regular and NotoSansCJKjp-Regular are similar
> but different fonts.
I've noticed that utf-8.ly confused the font names.
It requires the font `Noto Serif JP`.
https://gitlab.com/lilypond/lilypond/-/blob/d6b62def753b268fc5adfbe8443aa477d38395ef/input/regression/utf-8.ly#L30
And
> I've noticed that utf-8.ly confused the font names.
I've created a merge request.
https://gitlab.com/lilypond/lilypond/-/merge_requests/595
It solves the confusion of Japanese font names in utf-8.ly
but does not solve the `--dgs-load-fonts` warning.
> * when could/would we drop the PS backend altogether?
In my humble opinion,
the PS backend is still needed for CJK character handling.
When you copy and paste text from a PDF generated by the cairo backend,
some CJK characters are garbled.
By the PS backend, no such garbling occurs.
Here's a sa
> I installed your Harano fonts in ~/.fonts. Fontconfig sees them, but I
> still get DroidSans when I compile the snippet. How do I reproduce the
> problem?
Would you show me the results of the follwing commands?
```
find ~/.fonts -name "HaranoAjiMincho-*.otf"
fc-list "HaranoAjiMincho"
lilypond -
> I analyzed more closely in the issue
> https://gitlab.com/lilypond/lilypond/-/issues/6172
>
> Would you know how the mapping of character index => codepoint is
> supposed to work for this font with character 3056 (辻) ?
Most PDF readers have a mapping
from Adobe-Japan1 CID to Unicode code points
>> Most PDF readers have a mapping
>> from Adobe-Japan1 CID to Unicode code points as follows.
>> https://github.com/adobe-type-tools/mapping-resources-pdf/blob/master/pdf2unicode/Adobe-Japan1-UCS2
>
> Is it impossible to discover this mapping from the OTF file alone?
If I understand correctly, y
Most PDF readers have a mapping from Adobe-Japan1 CID to Unicode
code points as follows.
https://github.com/adobe-type-tools/mapping-resources-pdf/blob/master/pdf2unicode/Adobe-Japan1-UCS2
>>>
>>> Is it impossible to discover this mapping from the OTF file alone?
>>
>> If I understa
> I analyzed more closely in the issue
> https://gitlab.com/lilypond/lilypond/-/issues/6172
The garbling sample I have shown has two different issues.
#6172 is one of them.
I created #6173 for the other one.
https://gitlab.com/lilypond/lilypond/-/issues/6173
he
>> PNG-transparency glitches fixed that surfaced in 2.19.51.
>> Ghostscript has made a release with the fix for the issue that was
>> created by Masamichi Hosoda as a result of the discovery of the
>> PNG-transparency bug in the 2.19.51 Lilypond build)
>
> That'
>> Phil Holmes:
>> ...
>>> /usr/bin/ld: cannot find -lfreetype
>> ...
>> ld cannot find libfreetype.so
>> Do you have it installed ?
>> Try this:
>> $ locate libfreetype.so
>> ...
>> /usr/lib/i386-linux-gnu/libfreetype.so
>> /usr/lib/i386-linux-gnu/libfreetype.so.6
>> /usr/lib/i386-linux-gnu/libfre
2.19.65 has been released,
it seems that it does not contain some recent translations.
e.g.
eb38c33a95 Doc-ja: fix cindex in NR
eccad9a9f8 Doc-ja: update Usage
1c1a932358 Doc-es: update one texidoc.
e7385f6e58 Web-es: update Introduction.
2cfed6cc93 Doc-es: update Notation/Simultaneous.
9f53d74eaf
I've noticed that ghostscript 9.22
will remove `PDFDontUseFontObjectNum` option.
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ca1ec9b486ddba3f921355fd1d775f27f4871356
So `--bigpdfs` will not work with gs-9.22.
It already did not work with gs-9.22rc1.
>> I've noticed that ghostscript 9.22
>> will remove `PDFDontUseFontObjectNum` option.
>>
>> http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ca1ec9b486ddba3f921355fd1d775f27f4871356
>>
>> So `--bigpdfs` will not work with gs-9.22.
>> It already did not work with gs-9.22rc1.
>
> Did they give
>> > Please give them a try on your system if you're interested in helping
>> > test the release-in-progress. Your feedback is appreciated.
>>
>>It seems that `-dPDFDontUseFontObjectNum` option does not work.
>
> It has been removed, as documented in History9.htm:
>
> 2017-08-02 13:41:59 +0100
>
> So the question then becomes 'why are the fonts subset ?' That's a
> really good question, and the answer is that I don't know. Its
> possible that there is a genuine pdfwrite bug here. The piece of
> information I'm missing is the step used to create the PDF files from
> the EPS files, I don't k
>>We use the following command to convert from EPS to PDF.
>>
>>$ gs -dSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
>>-r1200 -dSubsetFonts=false -sDEVICE=pdfwrite -dAutoRotatePages=/None
>>-sOutputFile=filename.pdf -c.setpdfwrite -ffilename.eps
>>
>>We believed that Ghostscript genera
>>If there is a full font embedded (non-subset) PDF,
>>does the bigpdfs trick work effectively?
>
> Its still, in my opinion, a risky thing to do. However, if the font
> were fully embedded, you wouldn't need to use Ghostscript and the
> PDFDontUseFontObjectNum bug approach (which is the risky par
> In my impression, if
>
> $ gs -dSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
> -r1200
> -dSubsetFonts=false -sDEVICE=pdfwrite -dAutoRotatePages=/None
> -sOutputFile=filename.pdf -c.setpdfwrite -ffilename.eps
>
> does not embed the completed font into PDF, Ghostscript developers
>
This discussion concerns two mailing lists,
some mails exist in both archives,
but other mail seems to exist only in one archive.
For convenience of people subscribing to only one mailing list,
both mailing list archive URLs are as follows.
http://lists.gnu.org/archive/html/lilypond-devel/2017-09/
> Note that I didn't attempt this on 9.21, just the 9.22 release
> candidate. While the fonts are properly dropped from the individual
> PDF files, none of the text was visible in the final PDF file, when
> rebuilding with Emmentaler supplied as an external font in fontmap.GS.
>
> Its interesting
[... replacing] 2.12.6 [... with] 2.12.93 indeed provides ~100x
improvement and builds the cache on my system in 600ms.
>>>
>
>>> This was a report of using fontconfig on Windows, IIRC. So my
>>> question: Does the Windows tarball of lilypond contain a recent
>>> fontconfig version?
>>
>> Ubuntu 14 for both. I would expect Ubuntu 16 to work but have not tried it.
>
> Not sure about that. We had several incompatibilities in the LilyPond
> code base since then (2.18.2 does not compile on current GCC versions)
> and GCC is written in C++ these days. Though the bootstrap process
>> GUB worked for a long time, but we have a) an unsolved problem
>> building the pdfs of the english documentation of stable/2.20,
>
> That sounds like more of a race condition to me, so it's likely
> unrelated to GUB but may be related to building in a separate directory
> or to cross-compilatio
> Masamichi Hosoda writes:
>
>>>> GUB worked for a long time, but we have a) an unsolved problem
>>>> building the pdfs of the english documentation of stable/2.20,
>>>
>>> That sounds like more of a race condition to me, so it's likely
>
I found a possibility that the wrong PDF is output
if the build directory is not clean.
>>
>> I've created the patch.
>> https://sourceforge.net/p/testlilyissues/issues/5380/
>> https://codereview.appspot.com/355750043
>
> Thanks a lot!
If I understand correctly,
there is a possibility
I've noticed that gs-9.26 cannot embed CID fonts
for the extractpdfmark method.
In the method, we defined fonts in PostScript, and use it in PDF.
gs-9.26 cannot define the fonts for PDF in PostScript.
https://bugs.ghostscript.com/show_bug.cgi?id=700367#c4
To define fonts for ghostscript,
root pri
> So it seems that you can save some hours of compilation time if you
> don't build the `bootstrap' target. I now wonder whether this is true
> on my openSuSE GNU/Linux box only ...
Sorry, I have not worked on GUB because I have no time for the time being.
Thank you for your work on GUB.
In my e
> Hi Werner!
>>> But building of lilypond-test fails.
>>>
>>> ./target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/lilypond-book/suffix-tely.texi2pdf.log:
>>>
>>> /home/gub/NewGub/gub/target/tools/root/usr/bin/texi2dvi: texinfo.tex
>>> appears to be broken.
But building of lilypond-test fails.
./target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/lilypond-book/suffix-tely.texi2pdf.log:
/home/gub/NewGub/gub/target/tools/root/usr/bin/texi2dvi: texinfo.tex
appears to be broken.
> This is a gs 9.26 issue and I cannot see how this might be related to what we
> have hit here, so maybe Hosoda-san will be abel to figure why make check is
> breaking without extractpdfmark installed.
If I understand correctly, this patch solves the error.
```
--- a/scripts/build/output-dista
>>> This is a gs 9.26 issue and I cannot see how this might be related to what
>>> we have hit here, so maybe Hosoda-san will be abel to figure why make check
>>> is breaking without extractpdfmark installed.
>>
>> If I understand correctly, this patch solves the error.
>>
>> ```
>> --- a/scripts
>>> Is dir guaranteed to be a relative path?
>>
>> It seems that there is no guarantee.
>> But, `make check` invokes `output-distance` with relative paths.
>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=GNUmakefile.in;h=da1f6f64e088756e07d20f8e1603ccc3a102053e;hb=HEAD#l340
>>
>> The
> $ uname -a
> FreeBSD freebsd-hyperv 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC
> amd64
> ld-elf.so.1: Shared object "libm.so.4" not found, required by "lilypond"
>
> Are there any further efforts anyone would like to see made here?
Maybe, installing compat6x package is required.
> Hello,
>
> Since I can't get a successful doc-build on my Fedora 30 box, I'm
> unable to check doc-changes and merge translation into stable.
>
> It's the same with extractpdfmark 1.0.2 1.0.3 and 1.1.0
>
> log spits:
>
> extractpdfmark -o ./out-www/collated-files.pdfmark
> ./out-www/collated-
> I ask because, in the german forum Arnold found a method to cure some
> windows-only bugs., about mis-predicted force and probably several
> assertion-failures:
> https://lilypondforum.de/index.php/topic,609.msg3463.html#msg3463
The patch is very interesting.
I've tried x87mant53.dll showed in
>> -fexcess-precision=style
>> This option allows further control over excess precision on
>> machines where floating-point operations occur in a format
>> with more precision or range than the IEEE standard and
>> interchange floating-point types. By
>> This sounds promising.
>>
>>> -fexcess-precision=standard is not implemented for languages
>>> other than C.
>>
>> Never mind.
>
> Hm. Maybe
>
> -mfpmath=sse
>
> instead? The problem with switching the whole FPU to reduced precision
> is that some library functions might
>>> You provided a lot of good information in your post, but the
>>> conclusion was not entirely clear.
>>> Are you suggesting requiring SSE2 at this time?
>>
>> Yes. It appears to get used anyway for 64bit executables, and it seems
>> safe enough to demand it for 32bit executables.
>
> +1
> far
> Nothing? I am currently proposing that we compile with
>
> -mfpmath=sse -msse2
>
> as options which should shift arithmetic off to the SSE2 instruction set
> which doesn't work with 80-bit arithmetic. That would be a default way
> of compilation.
I've created a patch for master.
https://sou
> We currently have the problem that the compiler used in GUB for
> compiling 32bit binaries gets an internal compiler fault for those
> options.
>
> We'll need to figure out whether a newer compiler does the trick, and if
> it does, update GUB. Or find a different way of proceeding.
>
> I'll se
n HUGE_VAL;
^
$ ~gub/gub/target/linux-x86/root/usr/cross/bin/i686-linux-g++ -c -msse2
-mfpmath=sse -I include -I .. rational.cc
$ ~gub/gub/target/freebsd-x86/root/usr/cross/bin/i686-freebsd6-g++ -c -msse2
-mfpmath=sse -I include -I .. rational.cc
$
```
>From 2a3816e49067e026c7180dc6a3b2d
nvincing LilyPond to do the same. So I cannot help
>>> with debugging this situation yet or even finding out whether it
>>> persists into newer compiler versions.
>>
>> I've attached the workaround patch for stable/2.20 branch.
>> The results of my experim
>> $ ~gub/gub/target/linux-x86/root/usr/cross/bin/i686-linux-g++ -c -msse2
>> -mfpmath=sse -I include -I .. rational.cc
>> $ ~gub/gub/target/freebsd-x86/root/usr/cross/bin/i686-freebsd6-g++ -c -msse2
>> -mfpmath=sse -I include -I .. rational.cc
>
> So this only affects darwin-x86 which confirms
Sorry, I'm too late.
As with the Java part of `pax`,
it may be possible to extract annotations from PDFs with a C/C++ program.
But, it looks like `latex-pax` is adding the extracted annotations
to the PDF using `pax.sty`.
The `pax.sty` is for LaTeX, and it looks like it is for pdfLaTeX only.
It wo
>> As with the Java part of `pax`, it may be possible to extract
>> annotations from PDFs with a C/C++ program. But, it looks like
>> `latex-pax` is adding the extracted annotations to the PDF using
>> `pax.sty`. The `pax.sty` is for LaTeX, and it looks like it is for
>> pdfLaTeX only. It would
> `gs` compiled from the current 'master' branch of the 'ghostpdl'
> repository makes a doc build fail if 'extractpdfmark' gets used: In
> the created `notation.pdf`, Emmentaler fonts are missing in all
> included snippets.
>
[...snip...]
>
> Sigh. Masamichi-san, please have a look!
It seems th
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
t;
> --
> Phil Holmes
>
>
> - Original Message -----
> From: "Phil Holmes"
> To: ; "Masamichi Hosoda"
>
> Sent: Friday, September 05, 2014 1:19 PM
> Subject: Re: lilypad.exe Japanese resource (menu, dialog, etc.)
>
>
>> - Original Message -
c.)
Date Fri, 5 Sep 2014 13:52:07 +0100
Message-ID: <40A388970C6540E08618DFC1C4932F1E@Advent>
> Now with the attachment :-(
>
> --
> Phil Holmes
>
>
> - Original Message -
> From: "Phil Holmes"
> To: ; "Masamichi Hosoda"
>
ilypad can do 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
Subject Re: lilypad.exe Japanese resource (menu, dialog, etc.)
Date Fri, 05
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 expe
> 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"
> To:
> 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
> - Original Message -
> From: "Masamichi HOSODA"
> To:
> Cc: ;
> Sent: Saturday, October 25, 2014 2:58 PM
> Subject: Re: GUB and mpfr/mpc
>
>
>>> - Original Message -
>>> From: "Masamichi HOSODA"
>>>
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));
/* Co
> Masamichi HOSODA 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 @@
>>{
>> str
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 writes:
>
>> In mingw, lilypond crashes as follows.
>> Does someone know this reason?
>>
>> ```
>> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>type test.ly
>> { c d e f g a b }
>>
>> C:\tmp\lilypond-2.19.16-
> Masamichi HOSODA writes:
>
>>> Masamichi HOSODA writes:
>>>
>>>> In mingw, lilypond crashes as follows.
>>>> Does someone know this reason?
>>>>
>>>> ```
>>>> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\u
>> Masamichi HOSODA writes:
>>
>>>> Masamichi HOSODA writes:
>>>>
>>>>> In mingw, lilypond crashes as follows.
>>>>> Does someone know this reason?
>>>>>
>>>>> ```
>>>>> C:\tmp\lil
> 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 o
, I tried to disable optimization only not one file whole, but one function.
In the case of Skyline::internal_merge_skyline, the result was bad_alloc.
In the case of first_intersection,
the result was that correct PDF was generated.
The source tree when succeeding, is as follows.
https://git
> 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-
>>> 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 r
>> 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.
>>> Also, the mention of optimization reminds me of one of the horrors of
>>> floating point types: a value in a register can quietly be changed when it
>>> is written to memory. Take a look at some of the “myths” in section 1 of
>>> https://hal.archives-ouvertes.fr/hal-00128124/en/ .
> […]
>>
>> 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'
> 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".
I
> >>> 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: fa
When environment variable PATH is undefined, the following error occurs.
```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>set PATH=
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond
GNU LilyPond 2.19.16
terminate called after throwing an instance of 'std::logic_error'
what(): basic
> 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,
https://g
>> 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, lin
> 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
> dep
> 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: Ubun
> On Mar 2, 2015, at 09:03 , Masamichi HOSODA 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.
T
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
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
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
> 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'l
>> 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
>> 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),
> 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
1 - 100 of 229 matches
Mail list logo
