• State Not Answered
  • Replies 2 replies
  • Subscribers 16 subscribers
  • Views 553 views
  • Users 0 members are here
Options
Related

String Height Issue?

DaveBrillhart
over 4 years ago

Strange. I can't seem to get a valid Text String Height. Obviously, the string "are" and "ARE" and "going" and "[Test]" all have different heights. Some have descenders, some like the bracket extend above even capital letters in CIQ (not here, where the bracket's top is aligned with the top of the "T").

However, the function "dc.getTextDimensions(msg,font)[1]" simply returns the entire Font's height, not the height of the string that is passed.

Is there any mechanism to get the actual height in pixels for a specific string?

Here is the output of my text code, sending a text string that should be about half of the overall height of the Font.

FONT: 4, MESSAGE: oae,  FONT HEIGHT: 48,  FONT ASCENT: 38  FONT DESCENT: 10  STRING HEIGHT: 48  STRING WIDTH: 57

It is strange the API includes a "getTextWidthInPixels". Because:

  1. that should be identical to getTextDimensions(msg,font)[0] (according to the documentation)
  2. they don't offer a "getTextHeightInPixels"

Seems they should fix the getTextDimensions function. Or if the real intent of that one is the capture multiple lines (\n) and use the Font Height... then offer a getTextHeightInPixels function to actually provide a string height.

  • 0 over 4 years ago

    This is the intended behavior.

    The result of a call to dc.getTextWidthInPixels() and dc.getTextDimsions()[0] should produce the same result for a given string.

    The dc.getTextWidthInPixels() and dc.getFontHeight() functions are closely related to dc.getTextDimensions(). The big difference is that dc.getFontHeight() returns the height of the font, and dc.getTextDimensions() returns the height of a block of text (separated by newlines) as would appear on the screen. We do not provide a way to get the height of a glyph or series of glyphs. We only report the font height.

    The data about the height/ascent/descent of individual glyphs is not available in the font data that we currently have. To capture this data would require changes to the font format and the graphics system, and would require more memory for each font that supported this additional data. I don't imagine that this is something that the device firmware would take advantage of, so there would be a pretty big cost for something that only a few ConnectIQ apps would benefit from. I just can't imagine that it would be considered.

  • 0 over 4 years ago in reply to Travis.ConnectIQ

    Ok Thank you. It turns out if you want to really know the top of the set of glyphs in a text string, you need to check the string for the presence of certain glyphs (like $), in which that central bar in the dollar sign actually extends about 12.5% above the value reported by getFontAscend. I've created a little function that searches a string, character by character to flag a string that includes descenders, and another flag for those characters that exceed the ascender value. And adjust. Allows me to fit a string more properly into a containing box. And better center a string within a box.