ASSERT (! FT_Render_Glyph(mFTFace->glyph, gFontRenderMode))

[lmiphay]

The viewer crashes whenever it tries to
render a Japanese character (such as ｲ) with the error message «ASSERT
(! FT_Render_Glyph(mFTFace->glyph, gFontRenderMode))». That is of course
an upstream bug, reported with no success in
https://jira.firestormviewer.org/browse/FIRE-31185
https://jira.secondlife.com/browse/BUG-231137
but I noticed that if I unmerge the kochi-substitute
font, then the bug isn't triggered, but also the viewer cannot render
the characters.

So, I wonder if anything can be done to circumvent the problem, by some
substitution perhaps. The unifont substitution doesn't seem to do much,
although it contains the characters.

Adding
/usr/share/fonts/unifont/unifont.ttf
/usr/share/fonts/unifont/unifont_sample.ttf
/usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc
/usr/share/fonts/noto-emoji/NotoColorEmoji.ttf
to the global fallbacks in /opt/firestorm-bin/fonts/fonts.xml did
nothing whatsoever.

[lmiphay]

This was tracked down to a version bump of media-libs/freetype.

When that moved from version 2.10.4 to version 2.11.0-r1, the shared libraries jumped a minor version as well:

/usr/lib64/libfreetype.so.6.17.4

to

/usr/lib64/libfreetype.so.6.18.0

That appears to have introduced an incompatibility between the viewer and system libraries.

I haven't had a chance to figure out a proper fix (assuming that there is one).

The current options appear to be:

1. rollback the media-libs/freetype (maybe serious implications for other clients, security issues... etc)
2. install a set of the old freetype shared libs into the viewers lib directory:

/opt/firestorm-bin/lib/libfreetype.so
/opt/firestorm-bin/lib/libfreetype.so.6
/opt/firestorm-bin/lib/libfreetype.so.6.17.4

[ntheo1979]

I can confirm this works.

[lmiphay]

Thanks @ntheo1979 - which option did you use? (number 1 or 2?). Neither option is great unfortunately.

[ntheo1979]

The second. For the record, I emerged =media-libs/freetype-2.10.4 with the -B option, which gave me a tarball of the build package but did not install it, then I opened it, stole the so files and copied them inside Firestorm's lib/ directory. It is of course a temporary solution, but for now it works. Thank you for it :-)

Of course, there are still characters unrendered, like Ⲙⲁⲥⳙ (coptic letters) and of course emoji. These should be rendered with the unifont substitution (or ideally a Noto font substitution, which I tried), but alas they are not. Have you got any insight perhaps?

[Miezhiko]

imo best solution will be simply to add patch to ebuild to catch such error

[lmiphay]

Possible solutions:

1. suggestion here: https://jira.firestormviewer.org/browse/FIRE-31185?focusedCommentId=218339&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-218339
2. wait for the next release and see if the firestorm team resolve the issue.

[Nicky-D]

I'll probably statically link freetype and fontconfig. If it will make it into the next release I cannot promise yet.

Please keep in mind that deleting those others sos in the ebuild to force system libs is still not a good idea. Though it probably does not matter so much with something as old and stable as SDL1

[lmiphay]

I have just pushed a new version of the ebuild. It has:

1. a possible fix for original freetype issue - it now pulls the firestorm 3p tarball and installs the so's from it - @Miezhiko if this works/doesn't work for you, please comment here.
2. add a voice use flag (per Request: Please add net-dns/libidn-compat to the second life viewers #17 ) - is this what you were thinking of @ntheo1979 ? Is voice support via wine the best approach (ref: https://wiki.firestormviewer.org/fs_voice )
3. added system-sdl use flag (default off) as per Nicky-D comment - hopefully it will be as stable as the system one has been (for a really long time).
4. added system-fontconfig use flag (default on) - based on https://jira.secondlife.com/browse/VWR-28748 description
5. continue to remove libpangox so's - they don't appear to be references by anything ( @Nicky-D would you like me to create a fs ticket for this?)

For reference the 3p freetype package README.Linden doc file includes this:

...
2. Modifications
...

On Linux, we either accidentally or intentionally ship without the
freetype library at all.  The result is that the viewer doesn't
run with these shared libraries.  We build with them then revert
(or upgrade) to system-provided libraries.  Accident or
carelessness, VWR-28748 suggests that users are better off as a
result.  We might want to either make this thing work well or get
rid of it entirely and let the host provide it.  For now, we'll
'upgrade' to what fontconfig is doing: fully-qualified .so shipped
but the symlinks missing so that the system libraries are used by
default.

...

[Nicky-D]

Regarding 1) Firestorm 6.5.4 will link statically against freetype and fontconfig, this is already changed in our git repository, tweaking this in the ebuild will the not be necessary anymore. For the next release (6.5.3) sadly it will be, as I made those changes after the release branch

2. Voice always has been flaky for OS users (not matter of OS). When it comes to Linux, we are stuck with an ancient 32 bit voice (thus you seen some multilib so's to make it work). Vivox has dropped voice support, so that is something we will never see 64 bit or being updated. So far though the old voice is still compatible, but this might break one day.
   Wine (sadly) is the safest choice, I would the suggest using the 64 bit slvoice.exe (using FSLinuxEnableWin64VoiceProxy debug)

3. SDL1 does not even get security patches anymore (afaik). So it should be super stable. For SDL2 from my knowledge SDL has a built in compatibility API layer

4. Fontconfig too will be gone (statically linked in 6.5.4+)

5. pango is also gonne in 6.5.4+, alongside with libffi and basically all that gtk, glib etc so's we had been shipping.

[Miezhiko]

@lmiphay I've made actually voice working natively on Linux in my Alchemy ebuild, ldd shows that you indeed must add libidn-compat for it to work. (also not sure about FS but for alchemy you need to download binary fmod for music streams), there example how I did it https://github.com/Miezhiko/Overlay/blob/mawa/games-simulation/alchemy/alchemy-9999.ebuild#L57-L63, so far I had no problems with hearing others at all, can't be sure about speaking myself because I didn't speak much.

[ntheo1979]

@lmiphay Thanks, I'll try it out within the next days (I'm kinda busy with RL right now).

Regarding voice, I can try the wine solution. Meanwhile, I installed @Miezhiko 's alchemy, which pulled libidn-compat as a dependency. I tried running it but it didn't open, as its dependencies are optimized for hardware better than mine, but I suppose its initial script ran. Long story short, @Miezhiko 's voice solution works (hearing and being heard). (And I can report I could hear streaming music even before, I just had no voice.)

@Nicky-D Regarding pango, gtk etc, it would actually be nice if you guys could convert to gtk3/4. It's only a few packages on my system that still need gtk2 and I've been trying to get rid of it for years now :) As far as I know, CoolVLViewer has made its own file chooser as a workaround to the gtk drama.

Given the occasion, I'd like to report a bug (or should I open a new issue?) Since switching to Gentoo, in all viewers (so it's probably something with Gentoo), when I use the compose key (or the Greek keyboard layout), the dead key appears as well. For example, when I type Compose+'+a, in general X I get á as I should, but in the viewers I get 'á. Similarly, when I type ;+α in the Greek keyboard, I get ά as I should, but in the viewers I get ΄ά.

[lmiphay]

Open a new ticket for this one @ntheo1979 - its probably unrelated to the freetype issue:

the compose key (or the Greek keyboard layout), the dead key appears as well. For example, when I type Compose+'+a, in general X I get á as I should, but in the viewers I get 'á. Similarly, when I type ;+α in the Greek keyboard, I get ά as I should, but in the viewers I get ΄ά.

[Nicky-D]

@ntheo1979 Firestorm 6.5.4 will use fltk and let fltk handle the UI framework. I believe this will get rid of the GTK2 dependency as fltk should use GTK3 if available. To be honest I have no tested this myself.

[lmiphay]

It seems that the freetype fix broke the loading of in-world web pages on prims:

2022-02-06T18:41:31Z INFO #LLProcess# llcommon/llprocess.cpp(697) LLProcess::LLProcess : SLPlugin (6659): launched cd /opt/firestorm-bin/bin/llplugin: /opt/firestorm-bin/bin/SLPlugin 41793
2022-02-06T18:41:31Z WARNING #Plugin# llplugin/llplugininstance.cpp(106) LLPluginInstance::load : apr_dso_load of /opt/firestorm-bin/bin/llplugin/libmedia_plugin_cef.so failed with error 20019 , additional info string: /usr/lib64/libharfbuzz.so.0: undefined symbol: FT_Done_MM_Var

The harfbuzz 1.4.2 and 2.7.4 so's from debian have the same result. I don't see anything later in debian: https://packages.debian.org/search?keywords=harfbuzz

Confirmed that reverting to copying the gentoo 2.10.4 era freetype so's back into the fs lib directory, makes web pages on a prim work again. They work against the current system harfbuzz 3.2.0. So that is a temporary fix at least.

Note: portage recently package bumped media-libs/harfbuzz to 3.2.0 from 3.1.2

The harfbuzz and freetype libraries need to be compatible. Would you know which version of harfbuzz fs 6.4.21 was built against @Nicky-D ?

Ref: PADrend/PADrendComplete#8 (comment)

[lmiphay]

And reverting the freetype so's back to the gentoo 2.10.4 versions broke compose dead entry of á for me @ntheo1979 - it had been working with the fs 3p freetype library... So somehow related after all.

[ntheo1979]

And reverting the freetype so's back to the gentoo 2.10.4 versions broke compose dead entry of á for me @ntheo1979 - it had been working with the fs 3p freetype library... So somehow related after all.

Indeed, @lmiphay. I just updated to -r4. FS's 3p-freetype libraries overwrote our own, and now the dead key problem disappeared. It did warn me about the media_plugin_cef failing, which is an issue, but a smaller one than the dead keys in my book, so I'm probably good for now until we find a better solution.

Also, I enabled your "voice" use flag, because running SLVoice.exe through wine slowed down my computer considerably. I'll stick around with the old Vivox 32-bit binary until it dies, I guess. Thanks for implementing it.

[ntheo1979]

Just to report. I updated to 6.5.3, with no changes other than the +voice flag. The viewer doesn't crash on Japanese etc characters, CEF is back, but so is the Compose/dead keys issue.

[lmiphay]

Hi @ntheo1979 - I see that compose/dead-key entry problem as well.

As far as I can tell the correct freetype so lib is being installed into /opt/firestorm-bin/lib - there isn't one bundled in the tarball for this release, and there is still a reference in the main binary to the freetype so:

/opt/firestorm-bin/bin$ ldd do-not-directly-run-firestorm-bin |grep freetype
        libfreetype.so.6 => /opt/firestorm-bin/bin/./../lib/libfreetype.so.6 (0x00007f2ee1887000)
/opt/firestorm-bin/bin$

Not sure what we can do at the moment on this.

[ntheo1979]

Hello @lmiphay !

It appears this issue has been resolved upstream. I downloaded FS 6.5.3.65658 from the upstream website and ran it as-is (with no modification whatsoever) and the bug doesn't appear. Also, the compose/dead-key issue doesn't appear either. The reference to freetype.so in the main binary seems to be gone too:

nikos@Archytas ~/Desktop/Phoenix_Firestorm-Releasex64_x86_64_6.5.3.65658/bin $ ldd do-not-directly-run-firestorm-bin | grep freetype

nikos@Archytas ~/Desktop/Phoenix_Firestorm-Releasex64_x86_64_6.5.3.65658/bin $

I have of course installed media-libs/freetype 2.12.0-r1.

However —and that happens with both the as-is ran viewer and with your packaged atom, and that's why I did that, to check—, for some time now, I think since the new version 6.5.3, if I paste to the viewer anything different than plain ISO-8859-1, it ends up as a series of unicode addresses, not the characters themselves.
Example 1:
What a fine morning, τί ὡραία ἡμέρα!
comes through as
What a fine morning, \u03c4\u03af \u1f61\u03c1\u03b1\u03af\u03b1 \u1f21\u03bc\u03ad\u03c1\u03b1!
Example 2:
ęéàâ€⇒ ∀a∈ℝ, a² ⩾0 comes through as \u0119???\u20ac\u21d2 \u2200a\u2208\u211d, a? \u2a7e0.

Also, pasting text from the viewer with the middle-mouse-button to my desktop (KDE Plasma, if it matters) takes ages (several minutes) till it appears. Pasting it with Control-C/Control-V or with right click copy/paste works as expected.

It's not a packaging issue, theoretically I should had told the Firestorm people directly. But that's not an easy feat (they never gave me a JIRA account), and I suspect you might know of some trick to package-magic a solution or workaround. I also didn't make another issue, since they might be connected.

My system's locales are fine, I think:

nikos@Archytas ~ $ locale
LANG=el_GR.UTF-8
LC_CTYPE="el_GR.UTF-8"
LC_NUMERIC="el_GR.UTF-8"
LC_TIME=en_GB.UTF-8
LC_COLLATE=el_GR.UTF-8
LC_MONETARY=el_GR.UTF-8
LC_MESSAGES=C.UTF8
LC_PAPER="el_GR.UTF-8"
LC_NAME="el_GR.UTF-8"
LC_ADDRESS="el_GR.UTF-8"
LC_TELEPHONE="el_GR.UTF-8"
LC_MEASUREMENT="el_GR.UTF-8"
LC_IDENTIFICATION="el_GR.UTF-8"
LC_ALL=

nikos@Archytas ~ $ locale -a
C
C.utf8
el_GR
el_GR.iso88597
el_GR.utf8
en_GB
en_GB.iso88591
en_GB.utf8
en_US
en_US.iso88591
en_US.utf8
POSIX

I wanted to attach the FS log in case you could make anything out of it, but I can't find how, forgive me.

[Nicky-D]

@ntheo1979 that's a known bug
https://jira.firestormviewer.org/browse/FIRE-31486 (and a few more)

Our Jira is open for registrations, so you can create a account here https://jira.firestormviewer.org/secure/Signup!default.jspa
(it was indeed closed a while due to spam and trolls, but is open since a few weeks again)

[ntheo1979]

Thanks @Nicky-D ! I'll wait for a new version then.