Hi Deri,
I understand the main problem with type 1 fonts is the 256 glyph
> restriction with pdfs, there is no such restriction in the font itself, I
> have Japanese type 1 fonts with more than 18000 glyphs which can be used in
> pdfs. Type 1 is dumber than more modern formats, but the glyphs them
On 5/21/23, G. Branden Robinson wrote:
> I think perhaps we should change this behavior.
>
> Most of the time I don't think it is what a user would expect.
I find your case for the change convincing.
On Tuesday, 23 May 2023 20:15:33 BST G. Branden Robinson wrote:
> I've tried a couple of times to start reading this, but the font is
> so fantastically ugly that it's making my brain wander off.
>
> Screenshot attached.
>
> Does the PDF not embed the font it's expecting? What is causing the
> i
On 5/21/23, G. Branden Robinson wrote:
> At 2023-05-13T12:52:06-0500, Dave Kemper wrote:
>> .nf
>> .ss 36
>> foo bar
>> .ss 48
>> foo bar
>> foo\h'1m'bar
>>
>> In Heirloom troff, the space on the first and third lines match. In
>> groff (both 1.22.4 and 1.23 rc4), the second and third lines do.
>
[self-follow-up]
At 2023-05-06T20:59:22-0500, G. Branden Robinson wrote:
> So I have a change pending for groff-next that will make the foregoing
> look more like:
>
> troff:man3/unlocked_stdio.3:123: warning [page 2, 1.8i (diversion '3tbd1,0',
> 0.3i)]: cannot break line
>
> What would build u
At 2023-05-07T14:22:14+0100, Deri wrote:
> On Sunday, 7 May 2023 03:57:57 BST G. Branden Robinson wrote:
> > Myself, I wonder if K-P couldn't be implemented above the formatter
> > itself, using a diversion. We could then put the implementation in
> > an auxiliary macro package. Since I have plan
On Tue, 23 May 2023, Douglas McIlroy wrote:
The new wording in groff(7) seems to explain everything--a great
improvement. But knowing how it works is not the same as knowing how
to use it.
I agree.
In the absence of any useful examples, I think a hazard warning in the
user guide is preferabl
Hi Tadziu,
At 2023-05-23T13:20:43+0200, Tadziu Hoffmann wrote:
> Eqn makes troff assemble a string named "10", and at the end
> of its output this string is interpolated:
>
> \*(10
Thanks for the reminder of another task for my GNU eqn(1) man page
rewrite queue:
*roff name space impact
When
Hi Doug,
At 2023-05-23T11:07:46-0400, Douglas McIlroy wrote:
> The new wording in groff(7) seems to explain everything--a great
> improvement. But knowing how it works is not the same as knowing how
> to use it.
True! groff(7) isn't, and isn't intended to be, good at that.
> In the absence of a
The new wording in groff(7) seems to explain everything--a great
improvement. But knowing how it works is not the same as knowing how
to use it.
In the absence of any useful examples, I think a hazard warning in the
user guide is preferable to an explanatory essay.
Maybe tabs in eqn should be off
> The tab is passed to groff as \t\, man 7 groff says \t is
> "uninterpreted", yet the tab skips to a tab stop set by .ta.
> This leaves me totally confused, because groff apparently
> ignores \t when it doesn't come from eqn. If, as i believe,
> eqn doesn't know about .ta and groff doesn't know
11 matches
Mail list logo
