| Age | Commit message (Collapse) | Author |
|---|
|
# Conflicts:
# CMakeLists.txt
# res/about/version.gmi
|
|
When multiple codepoints are in the same cluster, the hit test should only consider the first codepoint of the cluster, or otherwise the cursor is positioned somewhere in the middle of the cluster and not at the start.
|
|
In word-wrapped lines, a character will be hit multiple times and the
latest hit is what counts.
|
|
These options are mostly useful on mobile platforms that are not iOS or Android, and for testing purposes.
|
|
|
|
Emoji variation selectors would confuse cursor positioning and insertion behavior, breaking the assumption that each line ends with a single newline.
|
|
|
|
|
|
|
|
At a low level when measuring/drawing text, replace all characters with an override character.
|
|
Cursor movement and pasting.
|
|
|
|
|
|
Finding cursor position via coordinates. Handling the mark. Visual wrapped lines vs. content lines. Vertical scrolling inside the visual range.
|
|
|
|
`InputWidget` needs to be better at handling multiple lines. The previous implementation assumed that the content was short enough to be fully redrawn each frame, which is not a great idea when you have thousands of lines.
|
|
`run_Font_` was moving the Y cursor position twice for each line break.
Checking for the HarfBuzz UNSAFE_TO_BREAK flag leads to some unexpected behavior near edges of words.
The old `tryAdvanceNoWrap` method should return the maximum horizontal advance of the text, and not the cursor position's advance.
`draw_WrapText` used the wrong foreground color.
`TextBuf` now uses WrapText to do all the measuring and drawing, making things much simpler.
|
|
|
|
It appears HarfBuzz's script autodetection isn't working here for Arabic.
|
|
Updated the old simple text renderer for the new WrapText wrapping.
|
|
|
|
|
|
The base text direction of each line of text is determined when the document is laid out. When drawing runs, use this predetermined base direction.
|
|
There is still some weirdness with wraps that occur inside a bidi region. The problem is that text drawing is done later, in smaller segments, without knowledge of the paragraph base direction. The base direction should be saved into each GmRun as a flag.
|
|
|
|
The distinction between measure_Text and advance_Text was not very clear. Now there are only measure_Text functions that return both the bounds and the cursor position advancement, and the appropriate metrics are used by the caller.
|
|
|
|
|
|
AttributedText converts the text to a visual UTF-32 string. This allows it to be processed in a more straightforward fashion, and the indirection allows reordering via FriBidi.
|
|
|
|
|
|
Allow using both `pkg-config` provided libraries for local builds, and
configuring more minimal versions for distribution. HarfBuzz has a
bunch of dependencies by default.
TODO: ENABLE_FRIBIDI_BUILD should cause a static library to be built.
|
|
Todo: This seems a little late in the game. The reordering should be done for each paragraph of text.
|
|
|
|
If glyphs are borrowed from a different font, the offset/advance are adjusted to fit the correct monospacing (for pictographs/emoji).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This kind of already works! HarfBuzz will composite glyphs as expected.
Still missing: half-pixel offsets, line wrapping, color escapes, monospace grid alignment.
FriBidi will still be required to determine/reorder text direction within each run.
|
|
HarfBuzz will provide proper Unicode text shaping for both simple and complex scripts.
The old `run_Font_` is available for use as a fallback if HarfBuzz is not available due to size or complexity constraints (it's written in C++).
|
|
# Conflicts:
# CMakeLists.txt
|
|
|
|
|
|
It is possible that calling `SDL_RenderClear` was not performing the expected clearing of the TextBuf texture due to the wrong blend mode being in effect.
IssueID #271
|
