Координата передаваемая в TextOut относительно бокса символа Никак не могу получить точной информации о сабже. Допустим метрика в контексте по умолчанию пиксельная. Что за пиксель описывают аргументы TextOut (пусть TextOut принимает координаты первого символа). Т.е. включённый\исключённый он из бокса символа. Позиционируется относительно hight или ExternalLeading или ещё как то.
AsmGuru62 Не понял. Я спрашиваю про, то какое место эта координата внутри пикселей (или относительно пикселей) принадлежащих букве занимает. Я уже кажется после мучений определил. Это левый верхний пиксель принадлежащий символьному боксу, если область опеределения отсчитывать по верхнему из входящих строк в Height (т.е. отбрасывая ExternalLeading). Там пять величин в частях символьного бокса на которые можно ориентироваться (строить координаты) дробя поле пиксельных квадратиков, в которых рисуется символ. В описании TextOut ни слова не сказано какой конкретно из пикселей символьного бокса учавствует в определении координаты для TextOut. Ещё раз убедился что документация MS полное г%вно. Вот например FillRect принимает как аргумент RECT. Так мля ни слова про то какие координаты определяют входящие, а какие граничные пиксели. Поскольку координат 4е, то получаем 16 вариантов по граничности\принадлежности(2^4). Ничего серьёзно написать пока не узнаешь наверняка - невозможно. Эксперементально определил что первые две - входящие пиксели, а следующие граничные. Причём чувствую себя при этом дискомфортно, так как если в доке они ни слова не пишут, то вполне возможно предположение, что то,что я определил - точно только для GDI текущей версии. Они это специально так пишут или им вообще математика с логикой неизвестна и они "на глазок" рисуют?!
The Svin > "Вот например FillRect принимает как аргумент RECT. Так мля ни слова про то какие координаты ..." MSDN, RECT: "When RECT is passed to the FillRect function, the rectangle is filled up to, but not including, the right column and bottom row of pixels" "..точно только для GDI текущей версии" ИМХО открытое тобой правило действует с незапамятных досовских времен и менять его никто не собирается А сделано это из соображений удобства расчетов right=left+width и т.п. (хотя может есть и другие соображения
The Svin В подтверждение скромных намеков AsmGuru62 на Get\SetTextAlign, обратимся к первоисточникам MSDN сейчас под рукой нет, поэтому приведу цитату из Win32.hlp: Раздел Fonts and Text\Text-Formatting Attributes: Applications can use the SetTextAlign function to specify how Windows should position the characters in a string of text when they call one of the drawing functions. Windows positions a string of text by aligning a reference point on an imaginary rectangle that surrounds the string, with the current cursor position or with a point passed as an argument to one of the text drawing functions Далее приводится 3х3=9 возможных комбинаций вертикального и горизонтального выравнивания и рисуночек, иллюстрирующий работу TextOut (у меня к сожалению "не удается отобразить рисунок" И наконец: The default text alignment for a device context is the upper left corner of the imaginary rectangle that surrounds the text
Дык недостаточно было бы мне это upper left corner. Но за разъяснения спасибо к чему тут SetTextAlign leo и AsmGuru62 Я понял по крайней мере что во всех версиях она одинакова. Понимаете ли "воображаемый прямоугольник который окружает текст" - вот это как раз и есть то качество разъяснений, которое меня раздражает в MS. GDI не может оперировать точками в геометрическом смысле, точка - это то, что не имеет площади, как и линия - это то что не имеет ширины. На самом деле мы рисуем, раскрашивая квадратики. И если перевести все с этой точки зрения, то мыслить можно, например, в адресах столбцов и строк этих квадратиков. Когда же мне говорят в геометрическом смысле "точка находится в углу" я в эту систему квадратиков перевести однозначно это не могу, так как в этом случае точка находящаяся "в углу" может быть в равной степени отнесена к любому из четырёх квадратиков в её окрестности. А самое разъяснения "воображаемый прямоугольник окружающий текст" - это вообще не разъяснение даже для тех кто только начальную школу закончил, это - образ, который для детсадовского малыша, чтоб он "ухватил" направление идеи. И в конце концов это просто математически неверно даже как приближённая идея. Дело в том, что если пытаться рисовать такой воображаемый прямоугольник то он бы не "текст" окружал и не по нему ориентировался, он ориентировался бы по такой вещи как прямоугольная область рисования для данного шрифта. Разница между "текст" здесь в том что у такой области рисования, что для строчных, что для прописных букв, что для тех у которых есть какие-то точки над ними, что для тех у которых нет, что для тех у которых их нет - для всех была бы одинаковая высота этой области. Т.е. содержал бы текст символы определённого типа - прямоугольник бы уже совсем не окружал текст а оставлял просветы сверху и снизу, другого типа - просвет бы уже был только сверху, третьего - только снизу, четвётого - вообще бы не было. Т.е. обводил бы этот прямоугольник не сами символы а области отданные для его рисования. И "координата" описывала бы не "точку" а условно скажем "адрес" (в смысле адресации в Exel например) квадратика ориентированного в какой то части этой области. Сама эта область хорошо описана (опять же не MS а понимающими в описаниях людьми типа Петзольда и др.) и у меня было подозрение, что не вся она учавствует здесь при задании координаты (что учавствует именно она а не какой-то там непонятный "текст" вокруг которого воображаемые прямоугольники рисуются - я не сомневался). Область эта в данном случае будет InternalLeading. Т.е. координата описывает младший по столбцу и строке пиксел включённый в область рисования символа в части InternalLeading.
Совет: если надо вычислить размеры текста на поверхности Device Context - не надо использовать никакие параметры возвращаемые через TEXTMETRICS структуру или каким либо другим способом. Комбинация всех этих Leadings и других параметров не всегда приводит к правильному результату. Лучше всего - спросить сам Device Context через GetTextExtentPoint32. Конечно, сначала надо создать этот Device Context и выбрать в него шрифт через SelectObject, но зато нет проблематичных расчётов. Теперь, по поводу прямоугольника и пикселей - прямоугольник этот полностью покрывает текст. Самый левый верхний пиксель прямоугольника совпадает с левым верхним прямоугольником символа (это если параметры выравнивания не были изменены через SetTextAlign). Если изменить параметры выравнивания - точка начала рисования изменится, но останется ВНУТРИ прямоугольника символа.
Не надо. Я уже сказал, что надо - определение координаты для TextOut относительно символа. Это может быть верно а может быть нет в зависимости от того как ты определишь что такое "прямоугольник символа". Если ты определяешь под термином "прямоугольник символа" верхнюю часть по планке InternalLeading - то это верно. Если по классическому определению, либо любому другому - то нет.
The Svin 1) The rectangle that bounds the text is formed by the character cells in the text string 2) The character cell is an imaginary rectangle that surrounds each character or symbol in a Windows font. Т.е. бокс ячейки хоть и "воображаемый", но не как в голову взбредет, а это есть характеристика заданного шрифта Windows font. 3) Соответственно высота бокса для всех символов заданного шрифта фиксирована и равна TEXTMETRIC.tmHeight, возвращаемой GetTextMetrics 4) tmHeight=tmAscent+tmDescent, причем The maximum ascent and descent are different from the typographic ascent and descent, т.к. tmAscent включает в себя tmInternalLeading и это наглядно показано на рисунке в Win32.hlp в разделе Fonts and Text\String Widths and Heights 5) Разобравшись с боксом ячейки возвращаемся к RECT и делаем вывод, что по умолчанию left-top corner это левый верхний пиксел внутри бокса первого символа строки в области InternalLeading.
Я немного потерялся. То ли от том мы говорим, то ли о сём. Если о том, в каком месте пиксел в структуре\клеточках шрифта - так я понял давно, и уж написал, что понял. Если о том как документация MS об этом пишет, так все приведённые аргументы только больше меня убедили что криво. Утомило меня уже постоянное упоминание о картинке в Win32.hlp, видел я эти картинки и уже сказал (повторяюсь!) что структуру шрифта точнее описали Петзольд, Фролов и другие. То что ты написал - это догадки и логические заключения из разных обрывков из документации. Точно MS определения не даёт. А догадатся можно, грудные дети вон тоже только мычат, а мамки их как-то догадываются то ли какать хочет толи титьку пососать. Если бы документация была нормальной то была бы точно дана ссылка типа character box. И там была бы однозначная картинка какие мол части в charater box входят. У меня ощущение шизы полной. Ну и что что высота фиксирована? Откуда понятно то (где чётко написано) что по вертикали charater box включает именно куски структуры шрифта объединённые в hieght, Откуда в тексте документации то это чётко прописано? Hieght вещь условная она с hight реального символа может не совпадает, а если она не всегда совпадает то кто запретит так же предположить что кусок называемый ExternalLeading не может быть включён? Не надо мне больше писать "внутри бокса первого символа", у меня уже в глазах темнеет. Он не "внутри бокса" - он принадлежит боксу. Который сам по себе составлен из пикселей. Это не линия, нет линий в геометрическом понятии в машинной графике.
А чем вызван твой интерес к этой теме? Какую именно проблему надо решить? Или это чисто теоретический вопрос?
The Svin Дык никто и не утверждает, что в документации MS все описано четко и ясно. Действительно кое-что приходится домысливать, причем чем больше знаешь, тем больше вопросов может возникнуть. Я вот ламер, с Петзольдом, Фроловым и другими не знаком, дык у меня и не возникает вопросов и подозрений что за tmHeight может скрываться нечто иное нежели высота бокса ячейки, просто "умишки не хватает" Ладно пожалуй хватит разводить бодягу, сойдемся в общем мнении: MS - отстой )
Таблички я разные по работе делаю. Там нужно её правильно распологать и тексты внути ячеек позиционировать. Различные графические отображения сигнала с выделениями разными структур, где тоже рисовать нужно точно тест и разрираться програмно можно ли вообще это или как модифицировать. Т.е. я не могу сказать что это одна какая-то задача. Да, и спаcибо за участие. Моё раздражение в постах оно целиком к MS относится и конечно же не к вам
