CLIM mail archive
[Prev][Next][Index][Thread]
Re: postscript output with scaling and draw-text* in CLIM 1.1
> Date: Thu, 10 Sep 1992 12:15 EDT
> From: gmw@cypress.mitre.org (Gregory M. Whittaker)
>
> Scott,
>
> Perhaps I'm not being clear enough about this problem; there are really two
> separate issues involved. First, why isn't the start-point of the text glyph
> being transformed, and second, why aren't the glyphs themselves transformed.
>
>I think it is a simple bug in CLIM 1.1 that the start/end points are
>being transformed, although I find it somewhat surprising that there is
>a bug there at all.
>
> You have, I think, explained away the second problem, although I think that
> CLIM ought to supply some vector-based font for this kind of thing; but I
>
>CLIM is not in any position to supply this sort of thing, since it is
>explicitly not one of CLIM's goals to do rasterization or rendering of
>text. CLIM has to depend on what the underlying platform gives it.
If this is the case, then what do we make of the :transform-glyphs keyword in
draw-text in CLIM 2.0? The little escape hatch about implementations ignoring
this "if it is too expensive to implement" does not lead to confidence in the
specification of high-level descriptions turning into appropriate appearances
across multiple environments.
>
> still don't understand why the starting point for the draw-text* is not being
> transformed uniformly with the graph arcs. I'd be happy if the "nodes"
> remained fat or whatever font-size I specified, as long as they actually were
> planted in the right positions relative to the graph arcs. This is in fact
> what happens in the previous version that I sent when I use with-text-size.
>
> Previous version:
>
> (defmethod print-subclass-tree ((name symbol) &optional (size :tiny))
> (let* ((class (find-class name))
> (filename (concatenate 'string (string (class-name class))
> "-subclass-tree.ps")))
> (with-open-file (file filename :direction :output :if-exists :supersede)
> (clim:with-output-to-postscript-stream (stream file :multi-page t)
> (clim:with-text-size (size stream)
> (clim:format-graph-from-root class
> #'(lambda (object s)
> (write-string (string (class-name object)) s))
> #'clos:class-direct-subclasses :stream stream))))
> (excl:run-shell-command (concatenate 'string "lpr " filename))))
>
> The trouble with this approach is that the degree of compaction or expansion
> of the graph is determined by the text-size and does not cover the range of
> contraction that I need.
>
> If the starting points of the transformed arcs began at the end-points of the
> textual-nodes, and the start-points of the textual-nodes were at the end-points
> of the arcs then I could live with "untransformed" glyphs, but the way things
> stand now, the postscript output for the textual-nodes portion of the graph is
> identical no matter what I put in for a transformation size (using the code
> included below). I think that this much at least is a bug in the CLIM implemen-
> tation of 1.1. I only have documentation for CLIM 1.0 and 2.0.alpha. There is
> no mention of towards-x or towards-y in the 1.0 documentation, and the 2.0
> documentation is irrelevant at this point since 2.0.alpha dose not yet include
> with-output-to-postscript-stream.
>
>By the way, there are also problems in the PostScript port that cause
>the formatted output engines not to lay things out accurately. This may
>be biting you as well.
Maybe, but the fact that the postscript output is completely identical for the
nodes in the :size 1.0 case:
%! nonconforming
%%Creator: Symbolics CLIM
%%DocumentFonts: (atend)
%%EndComments
statusdict /waittimeout 30 put
/fontarray 30 array def
/f {fontarray exch get setfont} def
/estfont {findfont exch scalefont fontarray 3 1 roll put} def
/m {moveto} def
%%EndProlog
0 9 /Courier estfont
0 f 0.00 0.00 0.00 setrgbcolor
294 729.6 m (PREFERENCE-REQUEST) show
294 708 m (PIREP-REQUEST) show
204 718.8 m (ATC-REQUEST) show
294 674.4 m (ROUTE-CLEARANCE) show
294 652.8 m (SPEED-CLEARANCE) show
294 631.2 m (CROSSING-CLEARANCE) show
294 609.6 m (RESTRICTED-ALTITUDE) show
294 588 m (ALTITUDE-CLEARANCE) show
204 631.2 m (CLEARANCE) show
294 554.4 m (SIGMET) show
294 532.8 m (COMM-TRANSFER) show
204 543.6 m (ADVISORY) show
102 631.2 m (ATC-TO-PILOT) show
204 493.2 m (FLIGHT-PLAN) show
204 471.6 m (DEPARTURE-CLEARANCE) show
...
and in the size: 0.5 case:
%! nonconforming
%%Creator: Symbolics CLIM
%%DocumentFonts: (atend)
%%EndComments
statusdict /waittimeout 30 put
/fontarray 30 array def
/f {fontarray exch get setfont} def
/estfont {findfont exch scalefont fontarray 3 1 roll put} def
/m {moveto} def
%%EndProlog
0 9 /Courier estfont
0 f 0.00 0.00 0.00 setrgbcolor
294 729.6 m (PREFERENCE-REQUEST) show
294 708 m (PIREP-REQUEST) show
204 718.8 m (ATC-REQUEST) show
294 674.4 m (ROUTE-CLEARANCE) show
294 652.8 m (SPEED-CLEARANCE) show
294 631.2 m (CROSSING-CLEARANCE) show
294 609.6 m (RESTRICTED-ALTITUDE) show
294 588 m (ALTITUDE-CLEARANCE) show
204 631.2 m (CLEARANCE) show
294 554.4 m (SIGMET) show
294 532.8 m (COMM-TRANSFER) show
204 543.6 m (ADVISORY) show
102 631.2 m (ATC-TO-PILOT) show
204 493.2 m (FLIGHT-PLAN) show
204 471.6 m (DEPARTURE-CLEARANCE) show
...
indicates to me that there is just no transformation for the textual-nodes at all.
>
> Finally, I think it would be very useful for the with-output-to-postscript-stream
> to accept an additional keyword (:eps nil) for the purposes of including these
> views into standard document preparation software. I'm not grossly offended by
> the earlier suggestion you made of offering a kludgey :scale keyword also, but
> it does seem to clash with the overall transformation protocol.
>
>What does :EPS NIL do?
An :EPS keyword would control the output generation format making the resultant
stream an Encapsulated Postscript Stream if :EPS is non-nil.
--------
Cordially,
Gregory M. Whittaker, The MITRE Corporation
Center for Advanced Aviation
System Development
Internet: greg@mitre.org 7525 Colshire Drive
Phone: (703) 883-5549 McLean Virginia 22102-3481
FAX: (703) 883-1226 Mail Stop: W215
0,,
Follow-Ups:
Main Index |
Thread Index