Thanks, it worked pretty well.

Best Regards,
            Zhijian Zhang

On Mon, Feb 24, 2025 at 2:18 AM Elias Naur <mail@eliasnaur.com> wrote:
>
> On Sat, 22 Feb 2025 at 16:57, zhang zj <zhangzj33@gmail.com> wrote:
> >
> > On Tue, Feb 18, 2025 at 8:37 PM Elias Naur <mail@eliasnaur.com> wrote:
> >
> > >
> > > Thank you. I believe I followed your exact instructions using the
> > > hint edit box of the kitchen example:

On Tue, Feb 18, 2025 at 8:37 PM Elias Naur <mail@eliasnaur.com> wrote:

>
> Thank you. I believe I followed your exact instructions using the
> hint edit box of the kitchen example:
>
> https://imgur.com/a/gio-pinyin-input-hnSXtH7
>
> and got your expected results: "我们的". I'm on macOS 10.7.2, gio
> 4f720af6f2fedccac2a7bbc1f11efd0850ecbd21 and gio-example
> c6bccec3789a75a161a2c6d69a2c95ad6d0d8b93.
>

Could you please try in the multi-line editor of the Kitchen example ? And

Sorry, I missed the mail. Here is the precise instructions to
reproduce the issue:

1. Switch to "Pinyin - Simplified" IME in macOS.
2. Press the following keys: "women". The IME should display some
candidate words. Possibly "我们" is in the first place.
3. Press Space key to confirm the input. Then we'll get the words "我们“
shown in the editor.
4. Then try to type the chinese word "的" by pressing the following keys: "de".
5. After that the IME would give you candidates having pinyin "e", or
similar ones. And the first candidate should be  "额".
6. Press Space key to select the first candidate. This time we will
get the final result: "我们d额".

Text Shaper set the last empty line height to ascent+decent
of the paragraph break glyph which causes the last visual empty
line to have a smaller line height. This commit tries to fix it
by setting the line height using the line height from the last line.

References: https://todo.sr.ht/~eliasnaur/gio/629
Signed-off-by: zjzhang <zhangzj33@gmail.com>
---
 text/shaper.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/shaper.go b/text/shaper.go
index db679268..539ccb58 100644
--- a/text/shaper.go
[message trimmed]

> Absolutely. Another nice feature I'd like to see is the visible marking of the
> current composition (typically a blue underline).
>

Yes, that would be a nice feature to have if we can detect the
pre-composing text.


> Do you mean a regression compared to v0.7? If so, that's probably caused by
> https://gioui.org/commit/8107ec22066f3e4d308d1591057fb1f6e45be3f8

Possibly https://git.sr.ht/~eliasnaur/gio/commit/d7a1ec7 as I kept a
local version
of that. The issue can easily be reproduced, but the same key strokes may have

> Not that I know of. Note that I'm very much not an expert in IME and my
> efforts in that area has so far been to make the minimally viable
> implementation capable of working across platforms.
> I'd love your input as to how you think would be a better way, or
> extensions such as composition commit. One thing to know is whether
> such information is generally available from ~all platforms.
>

Thanks for your great work! I agree that Gio only provides minimally viable
implementation for what can also be done in the application layer. But I would
be nice to have more support for general tasks from the framework layer.
The IME behavior I reported above is ok for latin scripts, but I think
this is vital
for languages such as Chinese, as I think general users might expect revert the

Hi,

I tried to understand the how the IME works with Gio text editing
recently. There is a little problem
I found hard to handle. For each pre-composition, Gio sent a
key.EditEvent and a key.SelectionEvent.
The pre-composed text is inserted into the text buffer which is
important for visual cues. But there's a problem.
Undo operation would handle the pre-composed text as well, which makes
the undo look weird.

And in my case of using a Piece table buffer, the pre-composed texts
are appended to the add buffer
in an incremental ways which makes the buffer grow unnecessarily large.

Thank you, Jeff and Chris. These two options are inspiring. The later
option give us more control
of the width of the final "Tab" and could be useful if we have better alignment.

Best Regards,
            Zhijian Zhang

On Tue, Sep 17, 2024 at 9:31 PM Jeff Williams <kanobe@gmail.com> wrote:
>
> > > I am wondering whether it is possible
> > > to let the shaper replace tab (or any other rune) with some printable
> > > runes(one or more). Could anyone give me
> > > some guide?
> >

> What I have typically done is expand tabs to spaces when they are read
> by the shaper. The shaper accepts an io.Reader, and you can give it a
> special io.Reader that provides N spaces each time it encounters a tab
> in the original document.

That is really a good point! It is even possible to add a prefix
symbol to the expanded runes.

> That being said, I don't think overriding the unknown glyph tofu is a
> reliable way to fix this problem. It would also hide any other use of
> unsupported glyphs that were intended to be graphical.

Yes, this would cause chaos.

Hi,

I used a modified version of Gio editor to view code, and realized
that it does not handle control
characters such as tab(U+0009) as most fonts out there do not provide
tab glyph. I tried fonts with
tab character such as Ubuntu Mono. But I am not satisfied with the
result, because the tab width is
the same as space in a monospace font. So I am looking for other ways
to solve this issue.

I know that the shaper queries fontMap to find a glyph for the target
rune, when no mapped glyph is found,
it returns a placeholder glyph for it. And this is typically a