Re: [Emc-developers] Rockhopper revisited

[Gene H. <ghe...@wd...>]

On Friday 07 June 2013 21:36:55 Kent A. Reed did opine:

> On 6/7/2013 8:00 PM, Gene Heskett wrote:
> > I have used it several times, and I love the concept.  My main problem
> > is that the .svg output, when viewed on a firefox screen has a non
> > adjustable scale that is waaaay too small to be readable.
> 
> Actually, SVG has no intrinsic scale. "Scalable Vector Graphics" means
> just that. It's your browser which is causing you problems (and Firefox
> is not alone in not understanding fully how to display and manipulate
> SVG. Life used to be better when we all had to use Adobe's plugin SVG
> viewer but Adobe killed that project years ago.).
> 
So far back I hardly remember it.

> > And, if I make the halgragh.svg, then convert it to multiple pages of
> > letter sized paper, I need some sort of control over the scale of the
> > output.  The last one I made, 3 hours ago, of the hal file I'm working
> > on for my lathe, was, when converted and clipped to 8.25" x 10.5"
> > pages, totaled 20 pages.  If I had some sort of a scale control, I
> > could do that on 4 sheets and still be able to read it just fine.
> > 
> > I am inclined to edit the svg file, and divide the viewport by about
> > 3, which should shrink it down to 4 pages if I understand how this
> > works, but there is considerable doubt as to my understanding.:(
> 
> Well, that's the thing. SVG has no intrinsic scale so Graphviz helpfully
> adds meta information about what *it* thinks is the right size based on
> its internal settings.
> 
Humm, is there a Graphviz.rc file that can have its tires kicked?  That 
might even be a better idea.

> If you don't like the choice made by Graphviz you can fool the
> downstream tools several ways. First you can edit the width, height, and
> viewBox parameters in the SVG file as you suggest (be consistent,
> please). I think that's too much trouble and too error prone. Second you
> can simply lie to the ImageMagick convert program about the tiles you
> want it to create. Either way you are changing how much of the full
> sheet will end up on a single page (tile). Remember we are playing
> charades anyway. My first instructions skillfully segued past the fact
> that pixels are not the same as points but we did our computions as if
> they were. How the png image gets scaled during printing remains under
> your control.
> 
> If, for example, I tell convert to "-crop 1188x1548" (e.g., twice the
> width and height values given in my earlier message) it will dutifully
> place 2x2=4 times as much of the original sheet in each png file
> compared to before.

I thought about that approach too but I won't quite double it as that would 
go clear off the edges of the paper & I don't think this printer can do 
full bleed.

> If you still print the png file as 8.25in x 10.75in
> (e.g., now 144 pixels per inch), then you'll have reduced the scale of
> the output by a factor of 2 in each dimension, and the number of pages
> by a factor of 4 (approximately, depending on details at the edges of
> the diagram).

Next time, I'll multiply both figures by 1.65 just for grins & giggles.  
Thanks for confirming its a doable tweak. 
> > The other thing is we need a switch to enable a thin, dim, page
> > outline to aid in trimming more accurately, an outline that will show
> > in the printouts to aid us in windy area's, about 1 pixel wide.
> 
> Great idea. I think it might even be done with ImageMagick. Could be
> either full box outline (if you use scissors) or just printer's crosses
> at the corners (if you use a paper cutter). Give me a night to think
> about it. Graphviz and hence MakeHALGraph.py know nothing about this
> stuff.
> 
> > Thirdly, it needs a switch so it does draw the stuff thats there, but
> > disconnected.  That would be handy for both troubleshooting and
> > garbage cleanup in the .hal code.
> 
> Well, I happened to run the axis_mm configuration through
> MakeHALGraph.py this afternoon and the resulting diagram *does* show
> single-ended signals (Xacc, Yacc, and Zacc, for example, each of which
> has a source but no sink). In earlier messages, you talked about "dead
> ends," which I think is covered by what I just described. Now you are
> saying "stuff that's there but disconnected" which I could take to mean
> something different Please clarify.
> 
> Regards,
> Kent
> 
That would be something that I had cobbled up, but then bypassed, with the 
net input probably still hooked up, so 2 or 3 modules are there, and are 
being fed data, but the output isn't being used anymore.  That sort of 
stuff could be excised, saving a few cycles in the servo-thread I'd think.
But I tend to leave it laying there just in case I need to 'hook' it up 
again for something else.  I'm as packrat that way. 

Thanks Kent.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views 
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
Paranoia doesn't mean the whole world isn't out to get you.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.