Thanks for giving a thought about it. I'm actually not sure myself what makes sense.

I want measurements for layouting and input feedback purposes. For example, I'd want to compute the "logical" bounding box of text to draw a frame around it. A bitmap bounding box could return a tiny bounding box for "." (instead of the logical line height), or an arbitrary box (higher than the text height) if the text exceeds the line bounds somehow (think of "zalgo"). And of course it doesn't tell you the baseline. At least at this point, using the ASS property that the font size equals the "line height" stops being sufficient for vertical alignment. Or maybe I'm overthinking, and returning baseline and line count is all what is missing?

Moreover, I don't just want bounding boxes of the entire text. I also want to:

map coordinates back to a character/codepoint position (think of mouse selection of text)
return grapheme cluster boundaries and order
know the bounds of a certain character or text run (this could result in multiple rectangles if text is wrapped)
have enough information to perform ellipsization
know how many lines some text is (accounting for all weird methods you could do line breaks in ASS, but also when screen bounds or margins cause the text to wrap)

Some of these can probably be handled by the same mechanisms. Also, to return less data from the API and to make mapping between bytes and logical entities, I thought maybe a new special tag could be introduced, that "probes" boundaries of enclosed text, or if the text is empty, the position a cursor would take:

{\start_bounds(123)}some text{\end_bounds}

Where start_bounds takes an arbitrary user-set ID as argument. Each bounds run would return one or multiple rectangles. The C API might look something like this:

// Measures the text that an equivalent ass_render_frame would draw.
// res is an array of ASS_Bounds structs, and res_size is the maximum number of the array
// items that libass can write to. The function returns the number of items that were written to
// (or a negative value on error). If the return value is the same as res_size, there might have
// been not enough ASS_Bounds item to report all results.
int ass_measure(ASS_Renderer *priv, ASS_Track *track, long long now, ASS_Bounds *res, int res_size);

struct ASS_Bounds {
  // ID from the start_bounds tag. If the text got broken into multiple parts (like 
  // due to text wrapping), there may be multiple ASS_Bounds item with the same
  // ID.
  int id;
  // Line number, after text wrapping. 0 is the first line.
  int line;
  // Logical bounding box.
  float l, t, r, b; 
  // Text baseline relative to t.
  float baseline;
};

The user could easily determine the physical location of text fragments using this API. To determine the line count, you could use a start_bounds tag with an empty "probe" text range at the very end of the event. To determine the total bounds, the entire event text could be put into a single start_bounds text (which would also give you per-line information). We wouldn't allow nesting of bounds tags, so unfortunately you'd need to call this function multiple times if you want to know both the bounds of the entire text, and the bounds of some fragment contained within it.

Instead of this starts_bounds tag, this could be a more down-to-earth API that somehow makes every grapheme cluster or so into its own ASS_Bounds, and has a byte offset/count field instead of an id field. But then we'd probably need to return per-codepoint info, which assigns each codepoint to a grapheme cluster ID (what harfbuzz seems to do?). The glyph position would be given by ASS_Track index + byte offset into the ASS_Track text. Each glyph would have a cluster index, which index into a separate cluster array, which has the bounding box of each cluster.

Ellipsization could probably be a separate feature that is done by the renderer, maybe a new wrap mode.

Most of these things don't really have any use for a pure subtitle renderer. Is there anything you'd clearly consider out of scope and would not want to have in libass?

Also possible that this is too complicated as that I could implement at all.

Text measuring API? #348

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions