NSString drawing vs. String as NSBezierPath drawing

Question

Мне нужно выполнить эффективное тестирование ударов по (потенциально огромному) количеству компонентов, поэтому я представил все мои примитивы как экземпляры NSBezierPath. Все отлично работает до сих пор.

Теперь у меня возникают проблемы преобразования NSString объектов, в частности, отражающие их позицию в представлении: Я использую NSString (BezierConversions) категорию, например Apple, SpeedometerView для преобразования строк в Безье путей.

Путь Безье создал для строк выглядит великолепно, но позиционирует его, чтобы соответствовать позициям расположения NSString экземпляров в представлении не совсем работает, поэтому я полагаю, этот вопрос действительно о

• NSBezierPath и transformUsingAffineTransform: против .
• сочетание NSAffineTransform применяется к виду и NSString drawAtPoint:

в моем тестовом проекте даже тривиальный случай терпит неудачу :

Серый Безье представление строки нарисована с использованием:

NSAffineTransform *moveFinal = [NSAffineTransform transform]; 
[moveFinal translateXBy:x yBy:y]; 
[textBezier transformUsingAffineTransform:moveFinal]; 

и фиолетовая строка через

[testString drawAtPoint:NSMakePoint(x, y) 
     withAttributes:attributes]; 

те же атрибуты, те же входные позиции, другое место в поле зрения.
И только ухудшается с повернутым текстом.


UPDATE # 1

Похоже, это кипение вниз к различным ограничивающими коробки возвращенных

• NSString sizeWithAttributes:
• NSBezierPath bounds

Теперь экспериментирует с NSString бо undingRectWithSize

Answer 1

FWIW - Работает сейчас.

Использование boundingRectWithSize:options:attributes: с опцией NSStringDrawingUsesDeviceMetrics дает хорошие текстовые размеры для работы, включая фактическое ограничивающее поле, занимаемое строкой при рисовании, и смещение первого глифа.

компенсировало NSBezierPath вернулся из bezierWithFont: на эту сумму, и вы хорошо идти ..