Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bringing back line-at-a-time formatting #46

Closed
travisleithead opened this issue Feb 8, 2022 · 2 comments · Fixed by #48
Closed

Bringing back line-at-a-time formatting #46

travisleithead opened this issue Feb 8, 2022 · 2 comments · Fixed by #48

Comments

@travisleithead
Copy link
Member

By popular demand, and from several internal customer requests (both at Microsoft and at Google), we should support line-at-a-time rendering (see also: #41 which could be addressed by this.)

In recent discussion, it was suggested that something like a

FormattedText.formatLine(...)

might be a good starting point.
This was referenced Feb 14, 2022
Open
Open
@travisleithead
Copy link
Member Author

Proposed approach:

  1. Author creates a FormattedText instance using the current approach (e.g., format(...)), but does not bother providing constraints. As such, the text will be formatted/shaped all on one infinitely long line. Alternatively, they can provide the contraints that they want for their first line, knowing that all following lines will be wrapped to that constraint despite the fact that they may intend to change the constraints on the following lines... This step is about getting all the relevant text input into the metrics objects.
  2. The FormattedText instance will provide a reflowFrom API which takes a line number and an optional constraints reference. Reflow implies that the new contraints will only be applied to the specified line and any subsequent lines (as the new contraints are enforced).
    • As currently described, omitting a width implies infinite width, and similar for height. So omitting the constraints object is equivalent to providing an empty constraint object, which is equivalent to removing the contraints for the given (and following) lines.
    • Authors that didn't constrain the FormattedText instance at format time, may call reflowFrom(0, <new constraints>)
    • Authors that already contrained line 1 (index 0) will already have the first line metrics (and can render it), and then need only provide the new contraints for the next line: reflowFrom(1, <new contraints>). This will keep line 0 untouched, and only reflow line index 1 to the new contraints, which may add/remove lines as the contraints allow.
  3. With each reflowFrom call, iterating each line, the author can cut/slice the original text content into any set of contraints (or even start over with line index 0 if desired). At the conclusion of each reflowFrom command, all the text is formatted and can be optionally drawn, or any one single line can be drawn as the scenario necessitates.

@travisleithead travisleithead mentioned this issue Feb 16, 2022
Merged
travisleithead added a commit that referenced this issue May 9, 2022
@travisleithead
New capability: per-line formatting (#48)
f091d75 
This PR adds a new capability to FormattedText construction in order to provide "line-at-a-time" formatting: lines. Rather than formatting all of the constructed text in one shot (via `format`), the new capability instead performs partial formatting enough to identify the next line break given the specified inline size contraint. The mechanism to generate the lines conforms to the JavaScript iterator protocol. The output of each step of the iterator is a FormattedTextLine instance, and it is the responsibility of the caller to collect and place these lines as desired. Unlike `format`, results of the iterator are not collected under a single "container" object, and so FormattedText container-specific functionality will not be available for line metrics generated via this method.

Finally, the coordinate spaces section has been re-written: two coordinate spaces are introduced--one for easily handling pointer input, and one for easily handling relative line metrics regardless of writing mode/direction.

Fixes #46

---

* Teaser for per-line formatting in input text model explainer
* Revision to "thinking ahead" section
* Add line-at-a-time sample
* Bring back old "advanced scenario"!
* Coordinate Systems text update
* Add visual aid for coordinate section
* Drop example and reflowFrom in favor of iterator approach
* Align param 3 for format and lines

* Metrics: update overview
* Metrics: drop the proposal for custom lifetime behavior
* Metrics updates primarily to coordinate spaces...
@travisleithead
Copy link
Member Author

(Note the actual approach differs substantially from the proposed approach noted above.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

New capability: per-line formatting WICG/canvas-formatted-text
1 participant
@travisleithead