Re: odds and ends

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Tuesday 09 January 2007 19:19, Daniel J Sebald wrote:
> 
>> The demo "transparent_solids.dem" produces color differences
>> between X11 and PostScript.
> 
> 
> Well, since neither x11 nor postscript support transparency... Do you
> think the demo should refuse to run?

Do we have the mechanism to do that?  Saying that a terminal doesn't support transparency is fine with me.

> Should non-supporting terminals
> fall back to something in particular if transparency is not possible?
> What, exactly?

Falling back on something is fine, but it should be consistent across terminals.  I would think in this case that if x11 behaved the same as PostScript (i.e., the same color elements, but just not the transparency) would be fine.  Were you trying to implement transparency in X11?  Or will that come once the alpha-channel mechanics are there?

If non-supporting terminals fall back, a warning message seems pertinent so that the (new) user realizes that what they are looking at isn't transparent.


>> Also, somehow with the tori example I ended up with "view" and
>> "scale" coordinates in a huge sans seriff font... Here's how I did
>> it.  Run gnuplot and type:
>> 
>> load 'transparent_solids.dem' load 'transparent_solids.dem'
>> 
>> On the second load of the demo the first graph has the font too
>> large for the coordinates.
> 
> 
> Hmm, yes. That does seem to be a bug. I can't see why it would have
> anything in particular to do with transparency, though. Probably just
> a case of the last thing in the previous plot being drawn with a
> large font, and the coordinate-drawing routine is missing a font
> reset.

That is what I'm imagining.

> Same thing again.
> 
> You need to configure the pdflib font installation. On my machine
> it's in /usr/local/share/pdflib.upr You can put aliases for fonts
> that are not an exact match. For example, frscript=z003034l.afm
> (Chancery Italic) is a decent substitute for the font used in the
> Kuen's surface demo

OK, I wasn't aware of the pdflib.upr file, thanks.

I've found the PDF file describing the library documentation.  Good documentation, just had to find it.

I used ZapfDingbats.afm and get this warning:

PDFlib warning (ignored): [2504] PDF_findfont: Use 'builtin' encoding instead of 'iso8859-1' for font 'WingDings'

but I manage to get some output at least (stars instead of smileys and clubs instead of thumbs down).  At least PDFlib is a little more forgiving on this.

I see the following are directed by pdf.trm to use internal fonts of the PDF viewer:

    if ( (strcmp(PDF_fontNameCur,"Symbol") == 0) ||
	 (strcmp(PDF_fontNameCur,"ZapfDingbats") == 0) ) {

which could expanded:

Courier, Courier-Bold, Courier-Oblique, Courier-BoldOblique,
Helvetica, Helvetica-Bold, Helvetica-Oblique, Helvetica-BoldOblique,
Times-Roman, Times-Bold, Times-Italic, Times-BoldItalic,
Symbol, ZapfDingbats

In the PDFlib doc, there is a form of exception handling for C of this variety:

	PDF_TRY(myPDF) {
	    font_handle = PDF_findfont(myPDF, PDF_fontNameCur, "builtin", 1);
	}
	PDF_CATCH(myPDF) {
	    fprintf(stderr,"HEY!  I DON'T KNOW THIS FONT!!\n");
	    return;
	}

but I'm having no success (may be because I'm stuck back in the "helvetica" missing font mode).

Dan