~tainted-bit

Recent activity

[PATCH v3 2/2] font/opentype: add tests for Collection as a Face 6 days ago

From tainted-bit to ~eliasnaur/gio-patches

Added tests to make sure that opentype.Collection can be used as a
text.Face, and that it correctly implements fallback behavior for
glyph lookups.

Signed-off-by: tainted-bit <sourcehut@taintedbit.com>
---
 font/opentype/opentype_test.go      | 184 ++++++++++++++++++++++++++++
 font/opentype/testdata/only1.ttf.gz | Bin 0 -> 442 bytes
 font/opentype/testdata/only2.ttf.gz | Bin 0 -> 629 bytes
 3 files changed, 184 insertions(+)
 create mode 100644 font/opentype/opentype_test.go
 create mode 100644 font/opentype/testdata/only1.ttf.gz
 create mode 100644 font/opentype/testdata/only2.ttf.gz
[message trimmed]

[PATCH v3 1/2] font/opentype: support using Collection as a Face 6 days ago

From tainted-bit to ~eliasnaur/gio-patches

This change allows font collection files (extensions .ttc or .otc)
to be used as a text.Face. These files contain an ordered list of
SFNT fonts, each supporting a maximum of 2^16 glyphs. When used as
a text.Face, each rune in the string to layout or render will be
assigned to the first font with a glyph for that rune, or to the
replacement character from the first font in the file otherwise.

With this change, it is possible to support multiple unicode planes
in a single text.Face by using a Collection with more than one
internal SFNT file. For example, it is now possible to display
characters from the basic multilingual plane and emoji in a single
widget.Label by loading an appropriate OTC file.

Fixes gio#104
[message trimmed]

[PATCH] example/fonts: added demo of using multiple fonts 8 days ago

From tainted-bit to ~eliasnaur/gio-patches

This example demonstrates the use of fonts other than the Go font.
It displays some labels in Go Bold, Go Regular, Roboto Regular, and
Noto Sans. It also includes a list of "Hello, World!" strings in
the world's most popular languages to showcase the unicode coverage
of Noto. This list illustrates some weaknesses of the current font
rendering system, such as a lack of ligatures and improper handling
of right-to-left languages. This example will serve as a good test
for future additions to the font rendering system.

This example relies on opentype.Collection being usable as a
text.Face, and thus it requires the resolution of gio#104.

Signed-off-by: tainted-bit <sourcehut@taintedbit.com>
---
[message trimmed]

[PATCH v2] font/opentype: support using Collection as a Face 9 days ago

From tainted-bit to ~eliasnaur/gio-patches

This change allows font collection files (extensions .ttc or .otc)
to be used as a text.Face. These files contain an ordered list of
SFNT fonts, each supporting a maximum of 2^16 glyphs. When used as
a text.Face, each rune in the string to layout or render will be
assigned to the first font with a glyph for that rune, or to the
replacement character from the first font in the file otherwise.

With this change, it is possible to support multiple unicode planes
in a single text.Face by using a Collection with more than one
internal SFNT file. For example, it is now possible to display
characters from the basic multilingual plane and emoji in a single
widget.Label by loading an appropriate OTC file.

Fixes gio#104
[message trimmed]

[PATCH] font/opentype: support using Collection as a Face 17 days ago

From tainted-bit to ~eliasnaur/gio-patches

This change allows font collection files (extensions .ttc or .otc)
to be used as a text.Face. These files contain an ordered list of
SFNT fonts, each supporting a maximum of 2^16 glyphs. When used as
a text.Face, each rune in the string to layout or render will be
assigned to the first font with a glyph for that rune, or to the
replacement character from the first font in the file otherwise.

With this change, it is possible to support multiple unicode planes
in a single text.Face by using a Collection with more than one
internal SFNT file. For example, it is now possible to display
characters from the basic multilingual plane and emoji in a single
widget.Label by loading an appropriate OTC file.

Fixes gio#104
[message trimmed]

Re: [PATCH gio 1/2] widget: add optional password masking to Editor 22 days ago

From tainted-bit to ~eliasnaur/gio-patches

On 6/20/20 2:01 PM, tainted-bit wrote:
> On 6/20/20 12:36 PM, Elias Naur wrote:
>> Thank you for the detailed analysis. To summarize, the problems are
>> (1) the call frequency of layoutCaret and (2) references to laid out
>> text.Glyph.Rune and text.Line.Len.
>>
>> I've refactored Editor to track the visual caret position, solving
>> (1) and rewrote the caret movement methods to avoid referencing the
>> layout runes and utf-8 len, solving (2). See the patchset ending in
>>
>> 	https://gioui.org/commit/a21aefa8b73ce282d5de64b62e45094b0505a1de
>>
>> Commit https://gioui.org/commit/ffec83a001be70c169726b56cc293a839366c51f
>> adds Editor tests.

Re: [PATCH gio 1/2] widget: add optional password masking to Editor 22 days ago

From tainted-bit to ~eliasnaur/gio-patches

On 6/20/20 12:36 PM, Elias Naur wrote:
> Thank you for the detailed analysis. To summarize, the problems are
> (1) the call frequency of layoutCaret and (2) references to laid out
> text.Glyph.Rune and text.Line.Len.
> 
> I've refactored Editor to track the visual caret position, solving
> (1) and rewrote the caret movement methods to avoid referencing the
> layout runes and utf-8 len, solving (2). See the patchset ending in
> 
> 	https://gioui.org/commit/a21aefa8b73ce282d5de64b62e45094b0505a1de
> 
> Commit https://gioui.org/commit/ffec83a001be70c169726b56cc293a839366c51f
> adds Editor tests.
> 

Re: [PATCH gio 1/2] widget: add optional password masking to Editor 25 days ago

From tainted-bit to ~eliasnaur/gio-patches

On 6/17/20 8:02 PM, tainted-bit wrote:
> As a broader point, I agree that my patchset may be a case of premature
> abstraction with regard to the new editTransformer interface. We could
> make this work by cherrypicking only the caretRunes addition to
> editBuffer and the changes to Editor that make all caret-related
> functionality operate on a rune count basis. This gives up the ability
> to have the masked and unmasked data disagree about the rune count in
> the future without a similar patch, but removes the overhead of the
> interface indirection and makes the patch much simpler (but still
> touching a lot of Editor code for the above reasons). I'd be happy to
> prepare a revised patch with this approach if you think it is preferable.

I've preemptively convinced myself that this is actually the better
approach. I've submitted a simplified version in patch 11238. (Sorry if

Re: [PATCH gio 1/2] widget: add optional password masking to Editor 25 days ago

From tainted-bit to ~eliasnaur/gio-patches

On 6/17/20 6:04 PM, tainted-bit wrote:
> On 6/15/20 5:35 AM, Elias Naur wrote:
>> I'm not convinced the added complexity of an interface and in particular
>> caretRunes is necessary, since it is only used on layoutCaret where it seems to
>> me a byte caret is good enough. It's quite possible I've missed a subtle point;
>> can you give me a mask example that can't be done with just a wrapping
>> maskReader?
>>
>> It seems to me that as long as text layout and the editBuffer agree on runes as
>> visible entities, you *should* be able to replace each editBuffer rune with a
>> mask rune at layout, even if their utf-8 encoded lengths differ. Sure,
>> the maskReader.Read method may not be simple, but at least it is contained.

(Hopefully this email goes to the right place...)

Re: [PATCH] widget: add mask feature to editor 25 days ago

From tainted-bit to ~eliasnaur/gio-patches

See also https://lists.sr.ht/~eliasnaur/gio-patches/patches/11119 for
another patchset under discussion that takes a different approach.