Hi All,

        I just checked in the postscript native overbar printing support.  You
can now print overbars on non-vector text. (And of course, vector text,
which worked fine before.)  

        This brings me to a question I would like to ask:

Background:
        There is an rc command 'output-vector-threshold to set a threshold
number of lines in a single text string above which the backend will
silently output vector text instead of postscript text.  The default
value for this value in the system-gschemrc file is 3 lines.  I am
pretty sure that this was added because the previous postscript code
used the printer's built in line spacing code yielding strange results
when more lines were output. (Wrong vertical centering, horizontal
centering.) Three lines seems a good compromise for this situation.  The
new back-end does not use the printer's font metrics for line spacing,
but rather the constants for line spacing from inside gschem, so, the
need for this threshold should be greatly reduced if not eliminated.

Question:
        Should I:
        a) Remove the option completely, breaking anyone's local gschemrc files
that set this value?
        b) Deprecate the option, issuing a warning when this command is
executed, ignore the setting, remove it completely a few snapshots from
now?
        c) Set the default value to '-1' as a flag to tell the backend code to
not output vector text unless 'output-text "vector"' is set?
        d) Preserver the current behaviour and just set the default value to
'999999' as in system-gschemrc?

        I favour 'c' and will proceed down that path unless anyone objects.
This seems to me to give the least amount of surprise to users, and uses
a certainly invalid value as a flag, although I can't imagine a reason
to have 999999 lines of text in a schematic, I don't see the sense in
setting this number to a large value like that. Should someone ever
actually put that many lines in the schematic expecting PS text and get
vector text instead... ;-) POLA - Principle Of Least Astonishment
applies.

Mike
        
-- 
--------------------------------------------------
                              Mike Jarabek        
                                FPGA/ASIC Designer
  http://www.istop.com/~mjarabek                    
--------------------------------------------------


Reply via email to