~eliasnaur/gio

10 3

New font and UTF-8 icons

Details
Message ID
<d23f9ce5b667a32d1c5f83d3447e24f1@evereska.org>
DKIM signature
missing
Download raw message
Hi,For a button, I wanted to display the trash icon from UTF-8 (🗑).
Problem is, that it displayed as a square on the button in Gio. So I thought maybe the gofont family didn't have any UTF-8 icon supported.
In my terminal, I use the mono from the ubuntu-font-family, so I thought maybe it would work if I used it instead.
I used the same trick as for gofont and generated all the types of fonts from the ubuntu-font-family. It is available here: https://github.com/dolanor/gofontu and is used the same way: `gofont.Register()`Anyway, the UTF-8 icon still don't display, so I guess there is something else missing.

Tanguy ⧓
Details
Message ID
<BZ51DQYRLEZS.1W82NBI05PKPA@testmac>
In-Reply-To
<d23f9ce5b667a32d1c5f83d3447e24f1@evereska.org> (view parent)
DKIM signature
missing
Download raw message
On Sat Dec 14, 2019 at 1:44 AM Tanguy ⧓ Herrmann wrote:
> Hi,For a button, I wanted to display the trash icon from UTF-8 (🗑).
> Problem is, that it displayed as a square on the button in Gio. So I thought maybe the gofont family didn't have any UTF-8 icon supported.
> In my terminal, I use the mono from the ubuntu-font-family, so I thought maybe it would work if I used it instead.
> I used the same trick as for gofont and generated all the types of fonts from the ubuntu-font-family. It is available here: https://github.com/dolanor/gofontu and is used the same way: `gofont.Register()`Anyway, the UTF-8 icon still don't display, so I guess there is something else missing.
> 

Unfortunately, the custom gio font renderer doesn't yet support colored
font glyphs, sorry. You're welcome to open an issue.

-- elias
Details
Message ID
<21fdc519c07d22bc991fbb15cd75d7c5@evereska.org>
In-Reply-To
<BZ51DQYRLEZS.1W82NBI05PKPA@testmac> (view parent)
DKIM signature
missing
Download raw message
> Unfortunately, the custom gio font renderer doesn't yet support colored
> font glyphs, sorry. You're welcome to open an issue.
Actually, even non colored font glyph are rendered. I just get a square.
Details
Message ID
<BZ6PQ2N2AP14.24LKWQNM6X4EY@testmac>
In-Reply-To
<21fdc519c07d22bc991fbb15cd75d7c5@evereska.org> (view parent)
DKIM signature
missing
Download raw message
On Sun Dec 15, 2019 at 11:46 PM Tanguy ⧓ Herrmann wrote:
> > Unfortunately, the custom gio font renderer doesn't yet support colored
> > font glyphs, sorry. You're welcome to open an issue.
> Actually, even non colored font glyph are rendered. I just get a square.

Can you create a short reproducer somewhere? I'll take a look.

-- elias
Gregory Pomerantz
Details
Message ID
<974b3d73-9b9a-b9d8-0f65-9656fdaf4f6b@wow.st>
In-Reply-To
<BZ6PQ2N2AP14.24LKWQNM6X4EY@testmac> (view parent)
DKIM signature
missing
Download raw message
Hi, before the new font system, I was using a MacOS system font that 
includes a much broader set of Unicode glyphs than the default gofont. 
This font is stored in a .ttc file (truetype Collection) which cannot be 
parsed by the code in gioui.org/font/opentype. I would like to propose 
the following additional function in gioui.org/font/opentype --

ParseSFNT(*sfnt.Font) error

This will allow you to open and work with font collections via 
golang.org/x/image/font/sfnt and then register elements of these 
collections into GIo. Thoughts?
Details
Message ID
<443de6f19cbbd45060abf1b739041b11@evereska.org>
In-Reply-To
<BZ6PQ2N2AP14.24LKWQNM6X4EY@testmac> (view parent)
DKIM signature
missing
Download raw message
> Can you create a short reproducer somewhere? I'll take a look.
I made a reproduceable use case here:

https://gist.github.com/dolanor/e5f23896be3261a44bc634b468197e7e

On Ubuntu 16.04 (X11) and Android 9.0 (Samsung Galaxy S8)
Details
Message ID
<BZ71WAT2TXW6.3QULWOCAE0FX1@toolbox>
In-Reply-To
<443de6f19cbbd45060abf1b739041b11@evereska.org> (view parent)
DKIM signature
missing
Download raw message
On Mon Dec 16, 2019 at 5:49 PM Tanguy ⧓ Herrmann wrote:
> > Can you create a short reproducer somewhere? I'll take a look.
> I made a reproduceable use case here:
> 
> https://gist.github.com/dolanor/e5f23896be3261a44bc634b468197e7e
> 
> On Ubuntu 16.04 (X11) and Android 9.0 (Samsung Galaxy S8)

That gist uses the Go Font, that doesn't contain the trashcan glyph, as
verified with the GNOME character viewer "gucharmap".

I suspect what's happening is that the Ubuntu fonts doesn't contain the emoji
characters either. Most modern software probably has a fallback font for emojis
they use automatically. Gio doesn't (yet), so you'll need to find an emoji font
and use that explicitly.

-- elias
Details
Message ID
<BZ726EUSU66G.19QI8KHJKVUZA@toolbox>
In-Reply-To
<974b3d73-9b9a-b9d8-0f65-9656fdaf4f6b@wow.st> (view parent)
DKIM signature
missing
Download raw message
On Mon Dec 16, 2019 at 9:28 AM Gregory Pomerantz wrote:
> Hi, before the new font system, I was using a MacOS system font that 
> includes a much broader set of Unicode glyphs than the default gofont. 
> This font is stored in a .ttc file (truetype Collection) which cannot be 
> parsed by the code in gioui.org/font/opentype. I would like to propose 
> the following additional function in gioui.org/font/opentype --
> 
> ParseSFNT(*sfnt.Font) error
> 
> This will allow you to open and work with font collections via 
> golang.org/x/image/font/sfnt and then register elements of these 
> collections into GIo. Thoughts?

I'd rather keep the sfnt dependency out of package opentype's public API, so
that the underlying implementation may change in the future.

How about a

	func ParseCollection(src []byte) ([]*Font, error)

?

-- elias
Gregory Pomerantz
Details
Message ID
<3c73392f-c346-e9b3-3067-90691f9cc3de@wow.st>
In-Reply-To
<BZ726EUSU66G.19QI8KHJKVUZA@toolbox> (view parent)
DKIM signature
missing
Download raw message
On 12/16/19 1:35 PM, Elias Naur wrote:

> I'd rather keep the sfnt dependency out of package opentype's public API, so
> that the underlying implementation may change in the future.
>
> How about a
>
> 	func ParseCollection(src []byte) ([]*Font, error)
looks good. The only issue I can see is that the ttc file I am parsing 
is 28 megabytes long, so it might be nicer to provide a 
ParseCollectionReaderAt() function, which doesn't have to read the 
entire ttc file in order to pull out one or two fonts -- I'd like to 
avoid generating a 28mb []byte if possible. While we're at it we can add 
a ParseReaderAt() call that also takes an io.ReaderAt for a ttf file, 
but I'm not sure there is as much of a benefit there.
Details
Message ID
<BZ7LXS8YNLA2.3E9L21Q95KMHU@toolbox>
In-Reply-To
<3c73392f-c346-e9b3-3067-90691f9cc3de@wow.st> (view parent)
DKIM signature
missing
Download raw message
On Mon Dec 16, 2019 at 1:46 PM Gregory Pomerantz wrote:
> On 12/16/19 1:35 PM, Elias Naur wrote:
> 
> > I'd rather keep the sfnt dependency out of package opentype's public API, so
> > that the underlying implementation may change in the future.
> >
> > How about a
> >
> > 	func ParseCollection(src []byte) ([]*Font, error)
> looks good. The only issue I can see is that the ttc file I am parsing 
> is 28 megabytes long, so it might be nicer to provide a 
> ParseCollectionReaderAt() function, which doesn't have to read the 
> entire ttc file in order to pull out one or two fonts -- I'd like to 
> avoid generating a 28mb []byte if possible. While we're at it we can add 
> a ParseReaderAt() call that also takes an io.ReaderAt for a ttf file, 
> but I'm not sure there is as much of a benefit there.

Don't you have to know the collection format, in which case we might as
well just add

	func ParseReaderAt(r io.ReaderAt) (*Font, error)

?

(I don't know the .ttc format)

Alternatively, we could add a

	type Collection

	func (c *Collection) Font(i int) *Font

for lazy-loading, similar to what package sfnt does.

-- elias
Gregory Pomerantz
Details
Message ID
<d0ea6b26-eb2f-867b-c14d-b0975e6d0ff8@wow.st>
In-Reply-To
<BZ7LXS8YNLA2.3E9L21Q95KMHU@toolbox> (view parent)
DKIM signature
missing
Download raw message
On 12/17/19 5:04 AM, Elias Naur wrote:

> Alternatively, we could add a
>
> 	type Collection
>
> 	func (c *Collection) Font(i int) *Font
>
> for lazy-loading, similar to what package sfnt does.
Yes, this was my plan, just mirroring what sfnt is doing and passing the 
calls through. I'm not sure there is any gain to having ParseReaderAt, 
since either way I think it needs to read in the entire file. For 
containers there is a big performance gain of you are only looking to 
pull out one of the fonts.
Reply to thread Export thread (mbox)