CLIM mail archive
[Prev][Next][Index][Thread]

Re: postscript output with scaling and draw-text* in CLIM 1.1

    Date: Thu, 10 Sep 1992 13:09 EDT
    From: gmw@cypress.mitre.org (Gregory M. Whittaker)

    >    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.

It's a sad but true fact of life in CLIM that you cannot have complete
confidence in the appearance of anything drawn in the user interface,
with the probable exception of vertical and horizontal lines and
rectangles.  This is because for platforms that use different
rasterization algorithms, no amount of tweaking can make differently
shaped objects be the same.  Rasterization of ellipses and circles is a
prime area for losing.  And text is as well.  Text rotated by angles
that are not multiples of 90 degrees simply looks crappy on most display
devices, so implementations are free not to even try.

The CLIM 2.0 spec is quite clear on this subject.

    >
    >    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

Um, 1.0 and 0.5 are pretty small point sizes (1/72 and 1/144 inch high,
respectively, I think)...  What is the size of the text in this output?
Also, the PostScript port has had very little use or testing, so it
would not surprise me if there was a bug establishing the font.

    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.


0,,
References:
Main Index | Thread Index