Hi all,
Simple question, i’m on MacBook Pro (Retina, mi-2012) with Sketchup 2015 with Yosemite 10.10.1.
On a ruby script I try this:
webdialog.write_image filenam.to_s, 0, 0, 100, 100
but the screenshot is allways a full(webdialog)screen ?
100, 100 are never consider (?)
Thanks for your feedback.
best regards
hi
there are ways to ‘crop’ the image on a mac, but why do you only want part of a webdialog window?
the easiest is to do this first
orig_size = ( 200,400 ) # orig_size is whatever you started with
webdialog.set_size( 100, 100)
webdialog.write_image( filenam ) # filenam should already be a string
webdialog.set_size( orig_size )
btw: you should use () to avoid issues
Hm… I see this on my machine as well, SU2015 OSX 10.9.5. Looks like we got a bug. Wonder if it’s always been there or if it’s a regression…
(Edit: I see this at least back to SU2013.)
Hi tt
Its come from a long time
I’ve logged a new bug for this issue.
[@tt I knew it was somewhere… this link][1]
it’s the docs that are wrong, you need more args…
I would express them as
dlg.write_image(filepath , quality, left_margin, new_width, top_margin, new_height)
I have a working script that demonstrates cropping dlg1 image to make dlg2 with cropped.
[1]: How to Use Graphing Gem in SketchUp Plugin • sketchUcation • 1
The problem goes beyond just the docs (which are indeed wrong). The API does not behave sensibly when you pass the wrong number of arguments. In Denis’ example, per John’s reference the interpretation of the arguments should be
quality = 0
top_left_x = 0
top_left_y = 100
bottom_right_x = 100
bottom_right_y = (missing)
Since Ruby does not raise a wrong number of arguments exception, I must assume that the API treats the arguments as optional. But what sort of strange defaulting logic transmutes (0,100)->(100, missing) to full screen?
This is another case where the API should have returned a usable error or raised an exception and did not.
oddly I have one example where it works as expected, but when I try to extract just this bit out to a simple example, it works differently…
@steve can i send you the code? email me…
john
Right - that jogs my memory. I see in the source that quality should be there. I’m going to bump this issue to have the docs updated.
But you shuffled the remaining of the arguments. it’s top_left_x, top_left_y, bottom_right_x, bottom_right_y.
Correct.
This is the type of method where we should have been accepting an option hash instead. As the quality argument doesn’t always apply, and certainly not as a requirement if you want to crop part of the image.
@tt_su, what are the exact arguments that ‘should’ work?
heres an experiment, not using any args…
I’m using css to crop a view.write_image(file) in a hidden webDialog.
then dlg1.write_image(new) to create the cropped image used in dlg2.
what did come to light are ‘retina’ pixel doubling issues with webDialogs when writing and showing images…
I wrote a js function to reduce the final image by 4, which hopefully works, anyone want to test?
john
cheers @tt_su.
I had seen that, and your comment above re: my order being wrong, but for my mind, if I think more like css
dlg.write_image(filepath , quality, left, top, left + width, top + height) it actually works…
edited when i realised i was still cocking it up…
john
Interesting
On a PC with SU 2015 this works
active_view.write_image(file_name, width, height)
I must try this out with a web dialog
Different method on different class (View vs WebDialog). They take different parameters.
With dialog.write_image you can either pass in
dialog.write_image(file_name)
dialog.write_image(file_name, quality)
dialog.write_image(file_name, quality, top_x, top_y, bottom_x, bottom_y)
Sketchup lets you pass in 3, 4 or 5 arguments but ignores them.
On a pc you can pass in 4 different file formats along with the file name
bmp jpg png tif
quality works with jpg only and is a number between 0.0 and 100.0
0.0 is maximum compression and 100.0 is no compression