Hi,
On Fri, 2006-03-03 at 12:30 +0100, Wojciech Kazubski wrote:
<SNIP>
> EPS export should also have those new lines added. The only difference will
> be
> the first line so both f_print_init_header and f_print_eps_init_header could
> ne merged together with single if instruction. I propose to move the code
> that reads page size one level up (to f_print) and pass the size in mils to
> f_print_init_header.
>
> Is it OK for EPS to contain defined pages?
Generally EPS is for a single graphic element that will be embedded into
another document. The book I have here lists a whole bunch of
Postscript commands that are not supposed to be used inside such a file.
I would like to re-organize a big chunk of the printing system.
Currently Gschem outputs quite verbose Postscript code. The code writes
out primitive drawing commands for each element drawn. This is quite a
bit different than most other postscript output programs, where the
header contains drawing subroutines that can be written and debugged
seperately from the main code.
I propose the following changes to the Postscript printing code:
1) Change the current style of printing to include a prolog read from a
file on the disk and inserted into the output script. This prolog would
contain the needed drawing code subroutines. The output postscript code
will contain a comment indicating the location on disk that the prolog
came from so that other Poscript hackers know where to look to insert
black magic postscript additions. :-)
2) UTF-8 printing support. Import Wojciech's patches or something like
them that enables UTF-8 printing. Being careful to include all the
defined glyphs from the Adobe glyph list.
3) General cleanup and re-factoring of the code. Some things like scale
don't get propagated around very well. Identify where such information
is actually needed and collapse or expand functions as needed. Some of
these constants are needed to calculate things such as bounding boxes,
needed for #4 below.
4) EPS output support. Wojciech's patch also includes support for EPS,
I will merge that too. Some of his changes bring us closer to #3 as
well.
5) Overbar printing support. Add this to both the vector font printing
and to the native Postscript font stroking. We have to be careful with
this and to make sure it works with the UTF-8 strategy. Thanks DJ for
the example code. I will use it or something like it in the prolog.
>
> (this is for future)
> what should be set for each of multiple page; initial position? scale?
> Now everything is printed on single page, but printing large sheet on several
> pieces of paper may be considered.
I will keep this in mind, as it was a feature of another CAD program I
used before. That was something I liked when I did not have access to
an 11x17 printer.
Mike
--
--------------------------------------------------
Mike Jarabek
FPGA/ASIC Designer
http://www.istop.com/~mjarabek
--------------------------------------------------
