groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Still No Luck Accessing Characters From Zapf Dingbats (Or An


From: Henry McGilton
Subject: Re: [Groff] Still No Luck Accessing Characters From Zapf Dingbats (Or Any Other Strange Font)
Date: Sun, 8 May 2016 15:27:02 -0700

Many Thanks for the various sources of advice.

Especially Werner and Ralph for spotting the ‘wrong’ quote signs.  

I recently had to install a new hard drive on my laptop, and while they
were at it, I asked them to ‘upgrade’ to El Capitan, and of course all
the default settings that are intended to be ‘helpful’ got turned on.
I turned them all off again . . .

So I am on El Capitan, and I am using the groff which comes installed
with El Capitan, GNU groff version 1.19.2

Invoking groff as suggested by Werner:

groff -k -Tps foo.tr > foo.ps

groff: invalid option -- k 


Werner, you had mentioned that input files should be in UTF8 encoding?
All my files right now are in simple ASCII text.  I can’t see why UTF8 encoding
would make a difference to just one character out of multiple thousands.
Can you clarify?

Carsten, yes, you are correct in that the Heirloom suite works, but that
had to have been after a lot of work to resolve all the warnings
and errors that the Mac OS compilers generate.    So, many thanks to
whoever did that work on Heirloom.

I did in fact go through about a week’s work of doing all that work myself
about a year or more ago, before I started looking at Heirloom.  
I ended up with clean code but a broken troff/ditroff . . .  
And I had no extended blocks of time to continue flailing . . .   

In the case of DWB 3.3, I have a clone of the master here, and building
via the default make script results in 130 or so errors and around 1400 
warnings,
essentially the same set of issues that I had seen with DWB 2.0.

Well, groff and its friends are a completely different code-base from DWB.
They replicate (and extend) the functionality.

These old documentation suites are hard to replicate, which is why I 
quickly give up on WYSIWYG and go back to something that gets
the job done.

For the edification of the other members of the list, go here:

        www.seroia.com

and click on the Sample button for pages out of the book.  A lot
of work went into pushing DWB 2.0 past its limits . . .

Ralph, also, thank you for the suggestions.    I see that the correct
font appears to be loading, and that the glyph in question is the
percent sign which maps over to the a202 procedure in ZD.

When I follow your instructions to  gs ding.ps, I don’t really see
much of anything, as it just seems to run and then stop.

Unfortunately, with El Capitan in the picture, I have no working PostScript 
viewer.    I have been using MacGhostView from Tom Kiffe, but the version
of XQuartz that is supposed to support MacGhostView is (still) broken.

Is there anyone on the list that is using MacGhostView on El Capitan and
who actually has it working?

As far as I can tell, the input side of the picture is working okay.  It’s the
production of the glyphs that are not functioning correctly.

    Best Wishes,
        . . . . . . . .    Henry



> On May 6, 2016, at 9:19 PM, Werner LEMBERG <address@hidden> wrote:
> 
> 
>>    lately I decided to try, try, try again to obtain characters
>>    from the Zapf Dingbats font.
>> 
>> The documentation GROFF_DIFF(7) suggests that I should be able to
>> inject a sequence to the effect:
> 
>        \f(ZD\N’37’
> 
>> (seems plausible) When I inject that sequence, I get the British
>> Standard Rectangular Lozenge which is groff’s way of telling me
>> that the glyph I want doesn’t exist.
> 
> This is the right sequence – however, your example uses Unicode quotes
> (U+2019) as delimiters.  To make that work, you have to add option`-k'
> to groff to call the `preconv' preprocessor, for example
> 
>  groff -k -Tps foo.tr > foo.ps
> 
> or
> 
>  groff -k -Tpdf foo.tr > foo.pdf
> 
> (assuming the above sequence is put into a file called `foo.tr' with
> UTF-8 encoding) since groff's native input encoding is 8bit only,
> normally latin1.
> 
> Using one of the two invocations, your example works just fine for me,
> showing a small telephone.  In general, however, I recommend to use
> ASCII characters only for control characters like delimiters; this
> simply makes life easier :-)
> 
> 
>    Werner



reply via email to

[Prev in Thread] Current Thread [Next in Thread]