> * 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
> [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
>> `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
> 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
> 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.
>> 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
> 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
> 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
>
>> `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
>>> 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
> 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
>> 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
> 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.
>> ```
>> 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
> * 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
> 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
>> 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,
> 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
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
> 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
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
>> 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
201 - 226 of 226 matches
Mail list logo
