Follow-up Comment #15, bug #65098 (group groff): [comment #14 comment #14:] > Hi Deri, > [...] > I won't prevail upon you to do that. I think it'd be better if we had a > superior font construction story in the first place so we don't have to > duplicate such workarounds for other fonts in the future.
I have some ideas for improving font handling in groff. Thanks to Kubo Koichi
I have a proof of concept version of gropdf which imbeds TrueType/OpenType
fonts into pdfs. It also provides ttftodit, avoiding passing through an afm
stage where some information can be lost. My ideal would be that groff's font
handling was extended so that as well as the current system directories there
would be a local cache of fonts (.local/groff - or wherever the proper place
for such files should be). This would contain just groff fonts and an index.
Further, the .ft and .fam (& .special) would have an extended syntax so that
if the name contained a path it is assumed to be a proper system font and
groff will search the index in the local cache and if not found groff will run
the appropriate tool (afmtodit/ttftodit) and generate a groff font, update the
cache index so that if that particular path is used again it will just use the
groff font it has just generated. If the path is found in the cache index
there is no need to generate the groff font again. It is likely the syntax
will also have to include some flags which need to be passed to the *todit
generators, although most of the flags currently required can probably be
algorithmically determined by analysing the unicode coverage of the glyphs,
i.e. the block and category. Similar to what is shown in the attached pdf
(glyph coverage of the U-S font).
> I still hold out hope for resolving bug #62932 some day.
>
>> I have noticed commit 66df2be1a90c88efda979305cde588c1ed3e3b7c
>> actually stops gropdf picking up the unicode number from the comment
>> field because it replaced "--\tcode" with "-- code", (I'm splitting
>> the line on tabs so it is one field less), but I do like the intention
>> of the patch, to stop the comment output if there is no unicode.
>
> Ah, I didn't notice _any_ collateral damage.
Yes, if you want a bookmark which contains a named glyph such as \[em], other
than names such as \[uXXXX] where the UTF-16 can be arrived at from the name.
>>> I ask for all this stuff because it's hard to get _gropdf_ to find
>>> "StandardSymSL.pfb" to embed it when running it from a build tree
>>> that is not also the source tree. That is a supported build
>>> scenario (and my usual one). The "download" file doesn't have any
>>> concept of source tree and build tree; to it, everything is an
>>> installation.
>>
>> I hope the patch to allow multiple -F flags simplifies the problem, SS
>> and the pfb file sit in the src until make install, the same way grops
>> treats its SS.
>
> It quite possibly will, and I'm eager to test it. I should observe in
> the meantime that I don't think anything else in groff parses a, uh,
> "search path supplementation option" (`-I` and `-M` come to mind on top
> of the aforementioned `-F`) as having an additional list structure, with
> the "runtime path element separator" serving as a field separator. Only
> the values of environment variables work this way.
gropdf already allowed multiple -I flags, since troff.1 specifically mentions
that multiple -I are allowed. -M is not passed to gropdf I believe.
> It's fine if gropdf(1) supports `-F foo:bar` as an extension, though.
>
> I'll double check that claim about other groff programs' `-[FIM]`
> options when I'm not in the midst of non-groff tasks, but if some
> language in troff(1) misleads the reader into thinking otherwise, please
> let me know.
Well it confused me (I know - easy) because the man page specifically mentions
multiple instances of -I, whereas the other two refer to environment variables
which allow "stacked" directories with ':'.
(file #57284)
_______________________________________________________
Additional Item Attachment:
File name: S.pdf Size: 47KiB
<https://file.savannah.gnu.org/file/S.pdf?file_id=57284>
AGPL NOTICE
These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-e283fc1e831e1a9d7ef799b94eb90b95407712b3.tar.gz
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65098>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
