Add_3d_text height
-
Thanks Dan for feedback.
@dan rathbun said:
3D_text is not a screen font, it's a 3D entity that's why the height is specified in inches. The 3Dtext is actually drawn with Sketchup edges and faces (approximating the given fontface,) then grouped.
Yes, I already understood all that and I also know how to hide the edges and how to move the group to the correct location etc. But I do fail to calculate the correct height (unless I would fall back on OS dependent Win32 textmetrics).
@dan rathbun said:
It gets smaller visually when you zoom out, and larger when you zoom in, so point size is really meaningless.
In my scenario this wouldn't be the case. I'm writing a converter from PowerPoint to SketchUp. Therefore the dimensions of the 3D text geometry must match other aspects of the conversion which are based on cm (or inch) measures. The PowerPoint TextBox shape is based on a font, where size is indicated in points.
Cf. the thread 'How to import a PowerPoint slide?'
http://forums.sketchucation.com/viewtopic.php?f=79&t=37610 -
Don't you already answer your question in your question?
original_texts_point_size = 144 3d_texts_inch_size = original_texts_point_size/72.0
2.0"
You can then use
3d_texts_inch_size
to make the 3d-text that height... BUT beware of making very small geometry... so perhaps make it .../7.2, and then scale the whole text-group's entities x0.1 when it's made ?
Sketchup/OpenGL have problems with creating small geometry [faces/edges] <~1mm, however once they exist with that size - e.g. after scaling down - there are no issues... -
Well TIG it's not that simple. 72 ppi is based on the old SVGA. Nowadays the dot pitches are smaller. My Samsung is 100 ppi.
I saw on MSDN some system calls and a formula for getting the display device context and a number that is plugged into the formula to get a corrected font height.
I see if I can find it again.
-
A 'point' [or PostScript Point] is 1/72 of an inch and an inch is 25.4mm.*
Its usual abbreviation is 'pt'.
Incidentally a 'pica' is 12pt...
'Points' are sometimes mistakenly thought as 'pixel units'; but points [pt] are not pixel units [px].
Points are physical length units; *in CSS and in PostScript there are 72 points in one inch.
Defining the font size in points on Web-pages is considered to be ill-advised.
There the size is best defined in 'pixels'... -
[About Device Contexts](http://msdn.microsoft.com/en-us/library/dd162467(v)
[GetDC Function](http://msdn.microsoft.com/en-us/library/dd144871(v)[Obtaining a Private Display Device Context (C source example)](http://msdn.microsoft.com/en-us/library/dd162744(v)
[Getting Information on a Display Monitor (C source example)](http://msdn.microsoft.com/en-us/library/dd144942(v)The formula I spoke of is given on this page:
[CreateFont Function](http://msdn.microsoft.com/en-us/library/dd183499(v)@TIG: What you describe, is the calculation for Device INDEPENDANT Pixel height. On Windows (API calls,) however, the font height is specified in Logical Units, which is the Device DEPENDANT Pixel height.
My current (unreleased) version of the Ruby Console Toolbar plugin, can change the console font to one that the user desires. But I need to encorporate the conversion formula because (on my high res display,) the resultant fonts are too small.
So I still need to get the user's device context and query it for information, that will allow me to calculate the Logical Units for the user's display, so that the fonts will appear at the correct size on their monitor. -
In a Windows program I would select the font and study text extents of a string like 'Åg' or then I could have a look at the textmetric structure of the font. In the TEXTMETRIC structure the measures are in logical units, i.e. they depend on the mapping mode. By selecting a HIMETRIC mapping mode the measure would be fine enough for our purpose.
This can be achieved with the Win32API module that Dan was referring to, but this would lead to a Windows only solution (which in this particular case would be adequate). I would, however, like to know how the 3D Text height should be calculated regardless of the OS (or monitor brands for that matter).
-
I got this far on my own:
require 'sketchup' require 'Win32API' GetDesktopWindow = Win32API.new("user32", "GetDesktopWindow", [], 'L') GetDC = Win32API.new("user32", "GetDC", ['L'], 'L') SetMapMode = Win32API.new("gdi32", "SetMapMode", ['L','N'], 'N') MM_HIENGLISH = 5 hwnd = GetDesktopWindow.Call puts "hwnd = #{hwnd}" hdc = GetDC.Call(hwnd) puts "hdc = #{hdc}" mapmodeDefault = SetMapMode.Call(hdc, MM_HIENGLISH) puts "mapmodeDefault = #{mapmodeDefault}"
Everything looks quite fine to this point. Now I would have to set up the TEXTMETRIC structure. I find the notations a bit difficult to grasp. So how should I declare TEXTMETRIC and pass it as a parameter in my GetTextMetrics call?
And what about this Ruby declaration:
GetTextMetrics = Win32API.new("gdi32", "GetTextMetrics", ['L','P'], 'V')
-
The declaration seems to be ok. And David Thomas' and Andrew Hunt's book 'Programming Ruby' seems to contain some helpful advice on how to pack and unpack binary data structures in Ruby. Cf. http://www.ruby-doc.org/docs/ProgrammingRuby/html/lib_windows.html, subtopic ClassWin32API (actually a quotation from the Ruby distribution, in ext/Win32API) - if someone is interested in how this is supposed to work.
The space for the data structure is reserved by initializing a string, which can then be referenced after using the unpack function.
lpTextMetrics = " " * 60 # TEXTMETRIC size GetTextMetrics.Call(hdc,lpTextMetrics) tmHeight, tmAscent, tmDescent = lpTextMetrics.unpack("LLL") puts "tmHeight = #{tmHeight}"
Thanks Dan and TIG for friendly help!
-
Just to clarify this (Ruby programming) topic a few steps further:
The full documentation for the unpack formatting 'directives' of the referencing string can be found in the 'Programming Ruby' book at:
Similarly, the documentation for the pack function - which transfers the contents of an array into a binary sequence - can be found at:
-
If you look at the top of the page, you'll that old book was written circa Ruby version 1.6.
Better to use the more up to date 1.8.6 Core reference:
Online
http://www.ruby-doc.org/core-1.8.6/index.htmlCHM
http://forums.sketchucation.com/viewtopic.php?f=180&t=10142&p=266725 -
Thanks Dan for updating my pointers. I cannot find the corresponding Win32API and win32ole documentation among these neatly structured pages. Could you kindly supply the references so that our thread is completed.
The Sketchucation thread is very useful indeed. Good work.
-
@pdonner said:
I cannot find the corresponding Win32API and win32ole documentation among these neatly structured pages.
Those are part of the standard extended libraries. The Core libraries (modules) are loaded when the Ruby interpreter is loaded.
Any non-core library module must be loaded afterward using require().
http://www.ruby-doc.org/stdlib-1.8.6/
Advertisement