Re: text question

[Alexander Malmberg]

Pete French wrote:
> 
> > You can't. GSHorizontalTypesetter does have an internal notion of a
> > baseline for each line, but that information is lost before it gets to
> > the layout manager.
> 
> Hmmm, as its a GS object would it be possible to add a method to obtain the
> information ?

Not in general, but I could do it for
GSHorizontalTypesetter/NSLayoutManager. However, it would be a bit ugly,
and I'd prefer not to.

> As it stands there doesnt seem to be a way to fix the bug
> properly.

This depends on what you mean by proper. We could document the method as
drawing the first glyph at the point (in a "show" sense, ie. the pen
position for the glyph, not necessarily any lower left corner of the
actual shape, or the lower left corner of the bounding box). Subsequent
glyphs would be placed in relation to the first glyph, which gives
predictable behavior for baseline adjustments and multi-line text. I
could implement this, and it should match what you expect for normal
single-line text.

> > A good approximation would be to get the starting location of the first
> > run of nominally spaced glyphs
> 
> Now theres interesting... I'd have to ignore the horizontal offset
> I preseme ?

IMO, yes. It makes more sense to place the left edge of the text
container at the point than to ignore any initial tabs or indentation
specified in the text.

> Whete does something like a capital 'V' start ?

The point I'm talking about is the "origin" in this figure:
http://www.freetype.org/freetype2/docs/glyphs/Image3.png (from
http://www.freetype.org/freetype2/docs/glyphs/glyphs-3.html ).

> > work if the text has baseline adjustment attributes, or if the text is
> > spread over several lines.
> 
> Is it possible to have an NSAttributedString which is spread over several
> lines ?

Yes, of course. Just include some newlines in the string.
NSAttributedString:s are the base for all text handling in -gui, so
anything you can do with the text system using NSTextStorage you can do
with the NSStringDrawing methods (including stuff like text attachment
cells).

We might want to limit this a bit and document the NSStringDrawing
methods as only handling some attributes. I could use a special layout
manager and typesetter for NSStringDrawing, but I want a very good
reason to do that.

> Drawing a simple string into a view should just draw left to right
> until its clipped at the edge I thought ?

The documentation doesn't say anything about it, but ignoring newlines
doesn't seem very sensible.

> Do you think I am possibly barking up the wrong tree by trying to fix the bug
> in this way ? Would it be better to fix drawGlyphsForGlyphRange:atPoint: ?

No, that method is correct. The point passed to it is the origin of the
text container in the current coordinate system.

> I havent yet found any bit of code I can point at and say "this is where it
> is going wrong" 

Nothing's wrong, it's just a bit unnatural. The text system works by
placing text in text containers, so aligning external points with the
text container is easy, but aligning with something inside the text
container (especially abstract typographical features) is tricky.

> after all - I'm just trying to fiddle it by applying an offset.

The fix will be applying an offset. The question is which offset, and
how to get it. :)

> -bat. [I think I might be out of my depth here and in need of help, sorry]

- Alexander Malmberg