> If I understand correctly, LilyPond needs to find the HaranoAji
> font, but Ghostscript does not need to find it.
OK.
> In Texinfo PDF building, you don't need Japanese fonts if only the
> included figure PDFs use the Japanese fonts.
Yes.
> If you want to use Japanese characters in the text
>>> 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
>>> [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
>
> OK, thanks for the suggestion.
After some thinking I'm not sure whether HaranoAji is the best
s
Am Sonntag, den 18.10.2020, 06:53 +0200 schrieb Werner LEMBERG:
> > > * Reduce the number of extra fonts as much as possible to not
> > > increase the size of the documentation additionally. [Not much
> > > a problem I think since most fonts will be subsetted by
> > > ghostscript.]
>
>
> > I
>> * Reduce the number of extra fonts as much as possible to not
>> increase the size of the documentation additionally. [Not much a
>> problem I think since most fonts will be subsetted by
>> ghostscript.]
>
> I'd prefer to focus on fonts that are widely available. DejaVu and
> Libertine a
>> [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
OK, thanks for the suggestion.
Werner
Am Samstag, den 17.10.2020, 11:58 +0200 schrieb Werner LEMBERG:
> Folks,
>
> some time ago I reported font problems in the documentation (this is,
> using fonts that are either not optimal, or not freely available).
>
> The basic question is which route we should go.
>
>
> * 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
Folks,
some time ago I reported font problems in the documentation (this is,
using fonts that are either not optimal, or not freely available).
The basic question is which route we should go.
* Reduce the number of extra fonts as much as possible to not increase
the size of the
>> OK. Could you please send me the list of available fonts in the
>> docker image?
>
> Get it with
> $ docker run --rm -ti
> registry.gitlab.com/lilypond/lilypond/ci/ubuntu-16.04:20200829 $cmd
>
> Attached is the full output of fc-list,
Thanks a lot! I think that we can easily adjust the
Am Montag, den 07.09.2020, 10:16 +0200 schrieb Werner LEMBERG:
> > We're talking about different objectives here: CI is concerned
> > *that* something can be built, but the *what* is discarded on
> > success.
>
> Understood now, thanks. However, I still think it simplifies
> debugging if the righ
> We're talking about different objectives here: CI is concerned
> *that* something can be built, but the *what* is discarded on
> success.
Understood now, thanks. However, I still think it simplifies
debugging if the right fonts *are* in the docker image.
> So everything added but not needed
Am Sonntag, den 06.09.2020, 22:02 +0200 schrieb Werner LEMBERG:
> > Am Sonntag, den 06.09.2020, 17:52 +0200 schrieb Werner LEMBERG:
> >> To make good doc builds of LilyPond it would be important IMHO to
> >> have all necessary fonts included in the docker images.
> >
> > Are these really important
> Am Sonntag, den 06.09.2020, 17:52 +0200 schrieb Werner LEMBERG:
>> To make good doc builds of LilyPond it would be important IMHO to
>> have all necessary fonts included in the docker images.
>
> Are these really important to ensure that the documentation is
> buildable?
No, but I consider it
Am Sonntag, den 06.09.2020, 17:52 +0200 schrieb Werner LEMBERG:
> To make good doc builds of LilyPond it would be important IMHO to have
> all necessary fonts included in the docker images.
Are these really important to ensure that the documentation is
buildable? The result is used nowhere (except
To make good doc builds of LilyPond it would be important IMHO to have
all necessary fonts included in the docker images.
Here's a list of 'foreign' fonts (or font families) that are not
correctly set up currently. In particular, I think we should avoid
non-free fonts for demonstration purposes,
Matthias Neeracher wrote:
Just my luck! My previous path used an API that changed in 2.5.28 so
lilypond would segfault. This one should finally work.
Here is a revised patch, based on the discussion we've had the last
couple of days. Basically, it does the same thing as the fontforge
based
Just my luck! My previous path used an API that changed in 2.5.28 so
lilypond would segfault. This one should finally work.
Here is a revised patch, based on the discussion we've had the last
couple of days. Basically, it does the same thing as the fontforge
based patch, but now is based on
Here is a revised patch, based on the discussion we've had the last
couple of days. Basically, it does the same thing as the fontforge
based patch, but now is based on fondu.
Although fondu is platform independent, my patch is preprocessor
bracketed to only compile on MacOS X, because some
Matthias Neeracher wrote:
On Jun 5, 2005, at 3:02 PM, Han-Wen Nienhuys wrote:
Matthias Neeracher wrote:
AFAIK, a .dfont is an archive of several TTFs, and should be
possible to extract the right TTF font from the .dfont directly.
Actually, we're not just dealing with dfonts here. Verdana,
On Jun 5, 2005, at 3:02 PM, Han-Wen Nienhuys wrote:Matthias Neeracher wrote: AFAIK, a .dfont is an archive of several TTFs, and should be possible to extract the right TTF font from the .dfont directly. Actually, we're not just dealing with dfonts here. Verdana, for instance, is a tradtional MacOS
Matthias Neeracher wrote:
Actually, we're not just dealing with dfonts here. Verdana, for
instance, is a tradtional MacOS font, as far as I can tell. Also, I
think that some font files may have the pfa font already embedded, so
going through the ttf version may entail a loss of quality.
Gotit
Matthias Neeracher wrote:
AFAIK, a .dfont is an archive of several TTFs, and should be possible
to extract the right TTF font from the .dfont directly.
Actually, we're not just dealing with dfonts here. Verdana, for
instance, is a tradtional MacOS font, as far as I can tell. Also, I
think th
On Jun 5, 2005, at 2:13 PM, Han-Wen Nienhuys wrote:Matthias Neeracher wrote: Yes, I guess that's best. I'd be grateful if you could find out how we can properly embed a dfont file. I know that there are utilities for extracting TTFs from dfonts. I think I found a solution that is reasonably gene
Matthias Neeracher wrote:
Yes, I guess that's best. I'd be grateful if you could find out how
we can properly embed a dfont file. I know that there are utilities
for extracting TTFs from dfonts.
I think I found a solution that is reasonably general: Why not pass all
unknown font files to
On Jun 3, 2005, at 2:08 AM, Han-Wen Nienhuys wrote:
Matthias Neeracher wrote:
It seems the changes in font.scm were harmful to MacOS X. On
processing, I get:
warning: don't know how to embed "Verdana"="/Library/Fonts/Verdana"
and in the resulting PDF file, the chord names look weird (I
b
Matthias Neeracher wrote:
It seems the changes in font.scm were harmful to MacOS X. On
processing, I get:
warning: don't know how to embed "Verdana"="/Library/Fonts/Verdana"
and in the resulting PDF file, the chord names look weird (I believe
it's Verdana substituted with Courier).
This s
It seems the changes in font.scm were harmful to MacOS X. On
processing, I get:
warning: don't know how to embed "Verdana"="/Library/Fonts/Verdana"
and in the resulting PDF file, the chord names look weird (I believe
it's Verdana substituted with Courier).
This seems to be related with pan
28 matches
Mail list logo
