> `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
>> 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
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
> 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
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
>> 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
> 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
> 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 -
> * 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'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.
> 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
>> ```
>> 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
> [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
>>> 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
> * 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
> 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
>> 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
> 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
>> `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
> 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
>> `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
>>> 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
> 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
>> 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
> 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
> 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.
> 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
>> $ ~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
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
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
> 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
> 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
>>> 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
>> 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
>> -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
> 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
> 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-
> $ 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.
>>> 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
>>> 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
> 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
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.
> 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.
> 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
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
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
> 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
>
>> 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
>> 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
[... 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?
>>
> 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
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/
> 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
>
>>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
>>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
> 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
>> > 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
>
>> 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
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.
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
>> 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
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'
> On 05/04/2017 10:27, thomasmorle...@gmail.com wrote:
>> LGTM
>>
>> https://codereview.appspot.com/320830043/
>>
>
> Detection is fine, but another piece is missing (tested on 2.19.58) :
>
> checking for guile... guile-1.8
> checking guile-1.8 version... 1.8.8
> checking for guile-1.8... guile-1
> Hello,
>
> I appear no longer to be able to make doc.
>
> I do not think it is for any particular checkin as I went back to
> before 2.19.57 was released and still have problems.
>
> The 'only' thing I did prior to that was to install
> texlive-lang-japanese to see if I could test Hosoda-san's
>>> I've created a patch and reported it to fontconfig Bugzilla.
>>> https://bugs.freedesktop.org/show_bug.cgi?id=99360
>>
>> I notice that Behdad is mentioned on this bugzilla page as the contact
>> person. However, he is no longer the maintainer of fontconfig, so I
>> ask you to also write an e
> GUB is not building correctly for me. The end of the command line
> output is:
I've created a patch.
https://github.com/gperciva/gub/pull/36
Sorry, I've not tested it.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mail
>> I've created a patch and reported it to fontconfig Bugzilla.
>> https://bugs.freedesktop.org/show_bug.cgi?id=99360
>
> I notice that Behdad is mentioned on this bugzilla page as the contact
> person. However, he is no longer the maintainer of fontconfig, so I
> ask you to also write an e-mail
I've found an issue of fontconfig on Windows.
If you have an old cache file and need updating,
the updating fails on Windows (both MinGW and Cygwin).
I've created a patch and reported it to fontconfig Bugzilla.
https://bugs.freedesktop.org/show_bug.cgi?id=99360
___
In my environments, autoconf does not raise such error.
Do you set the "set -u" or "set -o nounset" somewhere?
If so, would you remove the setting?
>>> The set -u (or to be complete set -ux) I discovered inside
>>>
>>> /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--li
> I've updated my GUB environment and the build fails. Please see the
> attached zipped logfile.
Perhaps gcc has upgraded but libtool has not been updated.
Does the folowing command
$ /home/gub/NewGub/gub/target/mingw/root/usr/cross/bin/i686-mingw32-gcc
--version
show 4.9.4?
And, does the foll
>>> In my environments, autoconf does not raise such error.
>>> Do you set the "set -u" or "set -o nounset" somewhere?
>>> If so, would you remove the setting?
>> The set -u (or to be complete set -ux) I discovered inside
>>
>> /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond
>>> Maybe the issue is to use ICU of CentOS system.
>>>
>>> I've created a patch.
>>> https://github.com/trueroad/gub/commit/081cc91f698186795dca45e8d6db8af6616826d4
>>>
>>> If this patch solves the issue, I will send the pull request.
>>
>> New gub bootstrapped from you repo; running a trialbui
>> In my environments, autoconf does not raise such error.
>> Do you set the "set -u" or "set -o nounset" somewhere?
>> If so, would you remove the setting?
> The set -u (or to be complete set -ux) I discovered inside
>
> /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-m
>>> New build from Masamichi’s branch passed the linux ppc harfbuzz, so the ICU
>>> patch worked. Now looking into a breaking freebsd-x86 lilypond error:
>>
>> Would you show me the whole log file?
> Went into a bit of experimentation afterwards, still failed attempts only,
> after discovering
> New build from Masamichi’s branch passed the linux ppc harfbuzz, so the ICU
> patch worked. Now looking into a breaking freebsd-x86 lilypond error:
Would you show me the whole log file?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://l
> Meanwhile took a look on the rest of the logfile and spotted a bunch of
> “checking <….>… no”… any of those a concern in your experience?
>
> checking for powerpc-linux-dlltool... no
> checking for dlltool... no
> checking for sysroot... no
> checking for powerpc-linux-mt... no
> checking for m
> I hope someone can shed a light on what I’m doing wrong here.
>
> librestrict:error:/home/gub/gub/target/linux-ppc/root/usr/cross/libexec/gcc/powerpc-linux/4.9.4/cc1plus:
> tried to open () file /usr/include/stdc-predef.h
> librestrict:allowed:
> /home/gub/gub/target/linux-ppc
> /tmp
> /d
>> I've had my last 2 tries to compile a GUB build today fail with the
>> same error. The last relevant part of the log is:
>
> Would you show me the whole log file?
If I understand correctly, I've found out the cause.
Is there the following line in the log file?
GPL Ghostscript 9.20: Can't fin
> I've had my last 2 tries to compile a GUB build today fail with the
> same error. The last relevant part of the log is:
Would you show me the whole log file?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinf
> Not related to the current guile2-problem, because it happens in the
> 2.19.51-docs as well:
> (1)
> The Japanese docs always display a Yen-sign instead of the backslash
> in the browser, although copying it into a utf-8-aware editor works
> well.
> See attached screenshot.
> Masamichi-San cc-ed.
> Hi,
>
> this is a single problem from
> http://lists.gnu.org/archive/html/lilypond-devel/2016-11/msg00090.html
> about pdf-meta-data with guile2
>
> In framework-ps.scm we have `metadata-encode' defined as part of
> `handle-metadata'
> There's the comment:
> ;; First, call ly:encode-string-
> But, I think that the simplest way is to distribute the tarball at the
> LilyPond site.
> e.g.
> http://lilypond.org/downloads/gub-sources/urw-fonts/urw-core35-fonts-79bcdfb.tar.gz
>
> And change the warning message of configure script.
> e.g.
> (download tarball from
> http://lilypond.org/down
>> I attached the shell script which can download the 12 font files from
>
> 'http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commit;h=79bcdfb34fbce12b592cce389fa7a19da6b5b018'.
>
>> Its each download URL is just link of each font file in above URL.
>> It works fine on my environment.
>
>>
> I am sorry to still talk about this, but I have been unable to work
> out
> how I could install just these fonts without having to clone the
> entire
> repo. I have looked in places like stackoverflow and the various 'git'
> sites but no one seems to be able to clearly state how to install just
>
>>> Do you have time to integrate this into lilypond in the near future?
>>
>> I would like so. My GUB environment can compile it for GUB inner
>> using. (v1.0.0 could not compile.)
>>
>> But, I think that the integration requires a lot of time.
>
> Why? Please elaborate.
At least, in order
>>> I've just tested successfully the following method, except item 1,
>>> which I've executed manually. [...]
>>
>> I've tried this way. [...]
>
> Thank you for your thorough testing, which obviously covers more
> situations than my limited tries.
>
> BTW, I see that your `extractpdfmark' tool
> The host machine is 64 bit debian stable I believe.
> This is the error I am getting:
>
> ail of target/mingw/log/fontconfig.log
> Alternatively, you may set the environment variables FREETYPE_CFLAGS
> and FREETYPE_LIBS to avoid the need to call pkg-config.
> See the pkg-con
>> Following up a conversation on the user list, as this might be a
>> better
>> place to ask... I think we've established that the only way to compile
>> for
>> Windows is to use GUB on Linux to cross-compile for mingw.
>
> Well I *think* Masamichi Hos
>>> https://bugs.freedesktop.org/show_bug.cgi?id=97546
>>>
>>> The proposed fix hasn't been applied yet to the fontconfig git
>>> repository – maybe we should downgrade GUB's fontconfig version to
>>> 2.12.0 until this is fixed.
>>
>> I think that there is another possible solution. To use the
>> Most likely cause of the issue will be the 2.12.1 change that
>> improved cache validation logic (and for yet unknown reasons always
>> invalidates the cache of the Mac OS System fonts)
>>
>> https://www.freedesktop.org/software/fontconfig/release/ChangeLog-2.12.1
>
> Aah, this rings a bell.
>
>> Hi,
>>
>> The new 2.19.47 is taking about 40 seconds to compile a one-note test
>> file.
>> (MacOS X x86.)
>>
>> In my past experience, new LilyPond builds sometimes take 30 or 40
>> seconds
>> to compile *on the very first run after install* (presumably to update
>> the
>> font cache, or someth
> Thank you for your answers.
> Is there
> /home/gub/NewGub/gub/target/tools/build/gmp-6.0.0.a/config.log
> ?
> Would you show me config.log in gmp-6.0.0.a ?
>
As far as I can see, that file does not exist on my system.
>>> Would you show me result of the following comm
Thank you for your answers.
Is there
/home/gub/NewGub/gub/target/tools/build/gmp-6.0.0.a/config.log
?
Would you show me config.log in gmp-6.0.0.a ?
>>> As far as I can see, that file does not exist on my system.
>> Would you show me result of the following commands?
>>
>>> Would you show me the following log files?
>>>
>>> /home/gub/NewGub/gub/target/tools/log/gmp.log
>>> /home/gub/NewGub/gub/target/tools/src/gmp-6.0.0.a/config.log
>
>
> Sorry - forgot to say. gmp-6.0.0.a/config.log is not present on my
> system. The directory is there but no file of that name
> I get the following:
>
> checking size of mp_limb_t... 4
> configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
> in this configuration expects 64 bits.
> You appear to have set $CFLAGS, perhaps you also need to tell GMP the
> intended ABI, see "ABI and ISA" in the manual.
> Comm
>> I'd like to suggest deleting `target/` such as in the GUB's basic
>> document.
>> But, after you delete it, GUB's full build takes a long long time.
>>
>
> Yes, I know :-(
>
> Should I revert my ABI change before trying the rebuild?
Yes, please.
__
>> GUB's basic document
>> https://github.com/gperciva/gub/blob/master/web/basics.html
>> says
>>
>> ```
>>SHARING DIRECTORIES
>>
>>GUB uses an ABI environment variable to work around some build
>>bugs in some packages. This variable is not checked by the
>>environment-changed func
> Apologies for the delay in replying. I knew it would take me a little
> time to gather the information you needed, so had to wait for some
> free time. Responses are below.
Thank you very much.
I suspect that environment variable ABI problem.
Have you ever mounted the disk to 64 bit OS?
Have
>>> FYI I had to make a small change to the GMP spec to accommodate 32 bit
>>> - my patch shows what I had to do.
>>
>> If you don't use the patch, do any errors occur?
>
> Yes: the terminal output has this:
>
> Tail of target/tools/log/gmp.log
> in this configuration expects 64 bits.
>
>> In my environment (Ubuntu 14.04 LTS 64 bit), the error does not occur.
>> Would you tell me the environment which the error occurs?
>
> Ubuntu 14.04 LTS 32 bit.
>
> FYI I had to make a small change to the GMP spec to accommodate 32 bit
> - my patch shows what I had to do.
If you don't use the
1 - 100 of 229 matches
Mail list logo
