vovchik, and everyone; I improved vovchik`s code ( I think...). Now GET_LABEL_SIZE only needs to be called once.
Also vovchik... Wouldn`t the func. be better called: STR_SIZE or TEXT_SIZE ?
Code pads width to 5 digits and height to 4 digits with leading 0s. A 1 is added to the start to hold the leading 0s in the returned value. So this will represent text width to 99999 pixels and height to 9999 pixels.
The dimension argument is no longer needed. You can tell where vovchik`s code ends and my code starts: l_height = FLOOR(ABS(xx)) + 1 l_width = FLOOR(ABS(yy)) + 1
' Add a 1 at start the start of the number to keep 0 padded value. ' Pad with leading 0s: width to 5 digits and height to 4 digits. w$ = FILL$(5-LEN(STR$(l_width)), ASC("0")) h$ = FILL$(4-LEN(STR$(l_height)), ASC("0")) dim = VAL(CONCAT$("1", w$, STR$(l_width), h$, STR$(l_height))) RETURN dim END FUNCTION And to parse out the returned data line: lsize$ = STR$(GET_LABEL_SIZE(test_label$, test_font$, langle)) lwidth = VAL(MID$(lsize$, 2, 5)) lheight = VAL(RIGHT$(lsize$, 4)) A returned string like: ( width$, NL$, height$ ) could be parsed easily with SPLIT.
# Thoughts: This shows the value of being able to return a string. For an include, a function`s return keeps the user from having to know the variable the data is in. So then it`s easy to include other folks code without knowing how it works.
# Suggestion: ( Peter must be choking on all my suggestions by now...). Leave the function as is for compatibility. Have the sub able to optionally return any data type.
# OR... At least a function be able to return an array of values. It`s a pretty commonly needed thing... .
When writing that function, I also thought about returing two values as a string that could be parsed but rejected the idea, since, with each invocation of the function, you would have to go through the conversion-to-dimension routine. I prefer two simple invocations of the function to having extra code being run for parsing and conversion each time something changes in the markup text. And, with my method, the function can be used directly in a MARK statement, for instance, without any post-processing (which could be cumbersome if you have lots of MARK statements, for example). There are pros and cons to each method, obviously. My function works along the same lines as HUG's SCREENSIZE(dimension).
As for the name of the function, I am open to suggestions and you can surely call it what you want in your code. STR_SIZE is OK, but there is a gtk C function for string size already - and it does not refer to pixel length but to number of chars. GET_MARKUP_SIZE is possible, too, but having actual markup in the string isn't a requirement for obtaining the pixel dimensions of a text bounding box, so maybe that isn't such a good idea either. I don't know.
'@ TODO put this into FUNCTION LOCAL mysvg,mypix LOCAL window , decoration ,image , image2 IMPORT "rsvg_init()" FROM rsvg$ TYPE void IMPORT "rsvg_term()" FROM rsvg$ TYPE void IMPORT "rsvg_handle_new()" FROM rsvg$ TYPE long IMPORT "rsvg_handle_write(long,char*,long,int)" FROM rsvg$ TYPE int IMPORT "rsvg_handle_close(long,int)" FROM rsvg$ TYPE int IMPORT "rsvg_handle_get_pixbuf(long)" FROM rsvg$ TYPE long IMPORT "rsvg_handle_new_from_file(char*)" FROM rsvg$ TYPE long IMPORT "gdk_pixbuf_get_width(long)" FROM gdk$ TYPE int IMPORT "gdk_pixbuf_get_height(long)" FROM gdk$ TYPE int 'IMPORT "g_object_get(long,char*,...)" FROM gob$ TYPE void IMPORT "g_object_unref(long)" FROM gob$ TYPE void
FUNCTION get_pixels_width_and_height_from_text (STRING text$)
dec$=CONCAT$( "<svg image='","my-image","' width='","100%","' height='100%'>" ,NL$) dec$=CONCAT$(dec$,"<svg width='100%' height='100%' x='0' y='0'>",NL$) '@ could setsome of this in vars , here the only one is text$ , have put preserve spaces IE more than one space + tabs allowed dec$=CONCAT$(dec$,"<text x='0' y='0' font-family='sans' font-style='normal' font-weight='bold' font-size='45' text-anchor='start' xml:space='preserve'>",text$,"</text>",NL$) dec$=CONCAT$(dec$,"</svg>,NL$,</svg>")
Hi alexfish; It is very similar And in the usual programming way, yet another method to accomplish it.
vovchik`s right, getting the data out of subs and funcs. is critical to how easy included routines are to use.
I made a file button + text box to popup GTK`s file picker. The problem is that the user needs to know variables in the include sub. It`s the only way to get the /path/file from the text box.
Unfortunately, unlike Bash, Bacon doesn`t have stdin and stdout. So you can`t catch a PRINT in the code the way you can from another file. So includes are a problem to get data from, but execs. are slower to load. I don`t like the idea of making everything an exec., but it is easy to pass data.
As promised a few posts back, or in the source, I said I would do a demo without actually writing any svgs to disk and reading them into images from disk. Here it is - all in memory, thanks to librsvg. And I wrote a function that acts like TEXT for inline svgs called TEXT_SVG, which does the updating. The sources and binaries are attached.