[tex-k] kpathsea: Suppression of warnings about \special commands

[Joachim Schrod]

>>>>> "PV" == Paul Vojta <vojta at Math.Berkeley.EDU> writes:
PV> On Wed, Jun 27, 2007 at 11:09:16PM +0200, Joachim Schrod wrote:

Paul,

>> I would like to get a feeling for the common view on that directive's
>> intent. What would you prefer:
>> 1) only warnings about unknown specials are suppressed and
>> warnings about problems in recognized specials are still issued,

PV> I agree generally with the decision to follow this path, but it
PV> should be noted that sometimes a driver (I'm more familiar with
PV> dvips than dvilk) will believe that it recognizes a special such
PV> as "xdvi:!(/usr/local/texmf/fonts/type1/bluesky/cm/cmmi7.pfb)" (by
PV> flagging a bunch of unrecognized keywords) when in fact it
PV> doesn't.

This is surely a problem. That's why I asked if one doesn't want to
introduce two special-warning-suppression options for TEX_HUSH, named
"special" and "unknown_special" (or whatever names we would come up). 
The former option would quiet the driver for any problems that appear
in special processing; the latter would implement the case (1) above.

TEX_HUSH option "special" would then conform to -hushspecials in your
xdvi.

PV> <feature request :-)>
PV>   xdvi allows specials to have a program-name: prefix, which causes
PV>   xdvi to process specials beginning with "xdvi:" but ignore specials
PV>   beginning with "dvips:", etc.
PV> </feature request :-)>

I have to admit that I don't understand what you want to say with
that paragraph.

As far as I can see, this is already xdvi's behavior, isn't it? You
allow an "xdvi:" prefix everywhere and -hushspecials can be used to
suppress all warnings on other specials.

Do you propose that the same feature is implemented for dviljk? (And
eventually for dvips, too?) At least for dviljk, this would be easy to
do.[*] I don't know the dvips code enough, though, to make judgement
about the amount of effort needed there. I will probably need to
change dvipdfm{,x} next, so I could check them and see what's up there
with special handling.

Best,
	Joachim

[*] Last week, I looked at the special processing code of dviljk for
the first time, because it dumped core and I needed to enhance it. It
is nothing to die for, since it does not properly parse a specific and
documented special syntax. A prefix, as proposed by you, is an easily
implemented enhancement; but to implement any real syntax checks, one
would probably better write the routine anew.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod				Email: jschrod at acm.org
Roedermark, Germany