GDL prob with text anchor pt rot and maintain text orient

[Erika Epstein]

I am adding some graphical hotspots to some 2D symbols so I can move the text when necessary. I also have 3 options for text orientation horizontal, vertical, and 'smart' (rotates w/sym but mirrors so not seem upside down).

When I have the text orientation options the anchor point of the text no longer is the same as the graphical hotspots. I tried many ADD2 and ROT2 options for the text location textx and texty with no acceptable results.Can someone point me in the right direction?

! graphical hotspots seripting
!!!!!Text ----------------------------------------
PEN txtpen
IF tr=1 THEN !HORIZONTAL TEXT
ROT2 -symb_rotangle
ENDIF

IF tr=2 THEN ! VERTICLE TEXT
ROT2 -symb_rotangle+90
ENDIF

IF tr=3 THEN !SMART ORIENTATION
mul2 1-2*symb_mirrored,1
IF symb_rotangle>90 AND symb_rotangle<270 THEN
ROT2 180
ELSE
ROT2 0
ENDIF
ENDIF


DEFINE STYLE "symtextstyle" font, 1/(2.83464567)*fontsz, txtanchor, txtFaceCode
SET STYLE "symtextstyle"
TEXT2 textx,texty , switch_text
DEL 1

[Anonymous]

Hello Erika,
I don't know what those periods are either.
What happens when you delete them ?
What happens when you move them right or left
out of the seventh decimal place from the left ?
Do you get an error when you check script ?
Isn't the seventh decimal place the one millions place ?
Maybe its some arithmetic convention like commas
between groups of three decimal places.
Thanks,
Peter Devlin

[Erika Epstein]

When I delete the numbers after the period I get a format error message.

When I delete the period and the numbers after script is ok, but angle of line changes and length altered slightly . Original line was 12" long.

When I delete the period the second Y value I now get a very long line.
1.4E+15 in the coordinates box (tracker doesn't show in the gdl windows). I wrote the number as it showed in the coordinates box.

Back in the main window of AC with this line placed I the x,y and r values all have E+ numbers when measuring the line.


Same with changing millimeters to meters for modeling.

When I change units to feet & inches, I get a real value for the x499811'-5 13/16" but the Y and r values are empty.

So no exponents in imperial measuring in AC.

[Anonymous]

Hello Erika,
There's that e again. I think you can get that e in imperial units.
You have to make the lengths bigger.

You might be interested in this thread where Oleg explains
what e means and I did an experiment with the Print command
that printed numbers with e in them.

http://archicad-talk.graphisoft.com/viewtopic.php?p=11694&highlight=rnd#11694

As to the other weird things you are discovering, I don't know.
But fascinating non the less.

Thanks,
Peter Devlin

[Barry Kelly]

Erika wrote:
Juha,
You jumped ahead to the anchor point problem. Some symbols have two lines of text. How do you keep them from running into one another when the scale changes? Or when someone changes the font size?


thanks!

You can REQUEST the height of the text once you have defined it.
You would think that if you add 2mm high text it would be 2mm high - but no, you have to allow for the line spacing.

REQUEST ("Height_of_style", "name", height) will give you the height in meters.
You can then divide by 1000 to get millimeters and multiply by a scale factor for various scales.

Here is a bit of code from one of my objects with multiple lines of text that will adjust to suit any scale.

DEFINE STYLE "style_large" fnt_sltn,
txt_title_size, 5, 1
xx=REQUEST ("Height_of_style", "style_large", style_large_hgt)
style_large_hgt=style_large_hgt/1000 * GLOB_SCALE *(100/GLOB_SCALE)

Of course I work in metric so will have to leave you to sort out the Imperial side of things.


The E-014 as has been mentioned means add 14 more decimal places to the number.
i.e almost zero.
I quite often just substitue 0.0 for the entire figure as it is easier to read the script.
It appears often with auto scripted objects but only when the point is close to zero.

Here is a 1000mm radius arc (drawn 90° anti-clockwise) with centre at 0,0
A line joins the ends of the arc (i.e. the segment).
Two more lines are drawn from the origin to the ends of the arc.

ARC2 0, 0, 1, 0, 90
LINE2 0, 0, 1, 0
LINE2 0, 0, 6.123031769112E-017, 1
LINE2 1, 0, 6.123031769112E-017, 1

Archicad has decided that the end of the arc is not quite at zero even though it was drawn snapping to the vertical constraint.
It seems sometimes zero is not always exactly zero.

Barry.

[Erika Epstein]

Thanks Barry. I'll give that a try.

Peter, that's an interesting discussion in the link. I will see if decimal feet or inches might have the e's show up in Imperial.

[Anonymous]

Hi Folks,

to Peter,

For Erika's object I used autoscripted code from lines and arcs located at the main origin of the 2d window simply dragged and dropped to the object 2d script.

Actually I did some tests... and it seems that I can see a pattern here...

The exponential numbers occur just with elements created using the special constrains (holding shift key to create orthogonal lines)...

I looks like the special constrains doesn't really locks the X as zero... but something very close to zero... which is that weird exponencial number.

When I use just x and y inputs to generate a line or an arc the autoscript code is clean... no weird numbers...

Could you guys please try to reproduce this?...

to Erika,

IMO... This periods between long numbers seems to occur when a coordinate is pointed with no precision... like an aleatory pick pointing...

The ArchiCAD engine try to give the coordinate as much precision as it can... so it gives you that great number of decimals...


It would be great if someone from GS could give us some light here...

I seems that we have discovered another giant cavern... Using Djordge's Speleology analogy for ArchiCAD hidden secrets...

[David Maudlin]

Barry wrote:
The E-014 as has been mentioned means add 14 more decimal places to the number.
i.e almost zero.

For one explanation of scientific notation, including the use of "E", see:
Scientific Notation
and scroll down to E notation.

David

[ztaskai]

Hi All,

Braza wrote:
...
The exponential numbers occur just with elements created using the special constrains (holding shift key to create orthogonal lines)...

I looks like the special constrains doesn't really locks the X as zero... but something very close to zero... which is that weird exponencial number.

When I use just x and y inputs to generate a line or an arc the autoscript code is clean... no weird numbers...

...

The ArchiCAD engine try to give the coordinate as much precision as it can... so it gives you that great number of decimals...

It would be great if someone from GS could give us some light here...

Sorry for my being late but in the final production phase of AC13 I'm pretty busy.

You figured out quite exactly what's happening. ArchiCAD stores the coordinates of placed elements at the highest available precision but it runs on computers which use a binary representation. So totally round decimal numbers get infinite binaries (which get truncated, of course) and finite binary numbers could produce infinite decimals (which get rounded, too). So 3.5 times 2 almost never equals 7 on computers - it's rather 6.999... or 7.00...00157... for example. If the difference is smaller than the rounding limit, you get 7 and don't notice anything. And as you guessed, computers use the scientific representation for very small and very large numbers. This usually happens for values very close to zero.

Consequence nr.1. When I create a script using AC drawing tools, I like to remove the 'almost zero' values, i.e. 1.34E-14 and its friends.

Consequence nr.2. Never compare real numbers using the equal and not-equal operators but use a small epsylon like the Technical Standards recommends.

Regards,
Zsolt

[Anonymous]

Hello David,
Thanks for the link to the Wikipedia article. It is now clear to me
there are two meanings of "e". Big E is scientific notation standing
for exponent and little e standing for the mathematical constant e
an irrational number approximately equal to 2.718. Which is what
was referred to in the GDL manual.
"EXP (x) Returns the xth power of e (e=2.7182818)".

Hello Paulo,
Thank you for your investigations and , as verified by Zsolt, correct analysis.

Thanks to all,
Peter Devlin

[Anonymous]

Thanks for the clarification Zsolt.

ztaskai wrote:
Sorry for my being late but in the final production phase of AC13 I'm pretty busy.

So... Next tasks... Buy some boxes of Champaign and call that cool DJ, right?...