Re: Text not rendered because of big offset in glyph bbox

--===============0446864373==
Content-Type: multipart/signed; boundary="nextPart3992894.9ob9zZpZbj"; micalg="pgp-sha256"; protocol="application/pgp-signature"

--nextPart3992894.9ob9zZpZbj
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Am Donnerstag, 11. April 2019, 18:23:24 CEST schrieb Uli Schlachter:
> Hi Rolf,
>=20
> On 11.04.19 11:20, Rolf Eike Beer wrote:
> [...]
>=20
> > My testcase is quite simple:
> >=20
> > pango-view "--text=3D|" -qo abc.png
>=20
> Any idea which font this is using? Does using a different font make a
> difference here, perhaps?

Liberation something, which are the only ones installed on the target.

> [...]
>=20
> > In my opinion this looks really strange:
> >=20
> > Breakpoint 1, _cairo_fixed_from_double (d=3D4) at
> > cairo-fixed-private.h:118 118         u.d =3D d +
> > CAIRO_MAGIC_NUMBER_FIXED; (gdb) n 120         return u.i[1]; (gdb)
> > p u $1 =3D {d =3D 26388279066628, i =3D {1024, 1119354880}} (gdb) p d $2
> > =3D 4
>=20
> Hm. This seems to be an endian issue. The fixed point value for "4" is
> "1024". However, your compiler seemed to be using u.i[1] instead.
>=20
> [...]
>=20
> > Can anyone give me a hint where I need to poke to get that right?
>=20
> If you are building cairo yourself: Can you grep config.h for
> FLOAT_WORDS_BIGENDIAN? Apparently, for you that symbol is #define'd,
> but should not.
>=20
> The configure test that is used to decide ff FLOAT_WORDS_BIGENDIAN is
> define'd or not basically does the following:
>=20
> $ echo 'double d __attribute__((used)) =3D
> 9090423496703681033747047890550501147621169273561563201479712084405348886=
581
> 6695273723469097858056257517020191247487429516932130503560650002327564517=
570
> 778480236724525140520121371739201496540132640109977779420565776568942592.=
0;
> int main() { return 0; }' > t.c && gcc t.c && strings -a a.out | grep -E
> 'noon|sees'
>=20
> If it finds "noonsees", then floats are big endian. If it finds
> "seesnoon", then floats are little endian. If it finds neither, it
> complains.
>=20
> Well, there is also a special case for darwin. Are you on something
> darwin-y? If not, could you run the above command and see what it
> prints and if configure sees the same result?

This is Linux, but=E2=80=A6

the configure test uses not just grep, but

strings -a conftest$ac_exeext | grep -a=20

Because strings is not part of our chroot build environment this doesn't wo=
rk.=20
If I replace the "strings -a" with a simple cat or just do grep on the file=
=20
itself I get results:

root@devpool35:/tmp/e2/build/cairo# grep seesnoon endianess-safe         =20
Binary file endianess-safe matches

And now I guess this is the reason: I worked around that by simply setting=
=20
ax_cv_c_float_words_bigendian before, but had a typo in my check, so it was=
=20
writing the inverse value.

Thanks for the hint.

Eike
=2D-=20
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
=46on +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 G=C3=B6ttingen, Germany
Sitz der Gesellschaft: G=C3=B6ttingen, Amtsgericht G=C3=B6ttingen HR B 3160
Gesch=C3=A4ftsf=C3=BChrung: Heike Jordan, Dr. Uwe Kracke =E2=80=93 Ust-IdNr=
=2E: DE 205 198 055

emlix - smart embedded open source
--nextPart3992894.9ob9zZpZbj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iLMEAAEIAB0WIQQ/Uctzh31xzAxFCLur5FH7Xu2t/AUCXLA/7AAKCRCr5FH7Xu2t
/FUiA/4lPQmfcSzJxKJR5cnoV4DroY6hLbMuWelh8WblvUDaUbwxT/bu9mTJuV2A
x1IyeMeRKNMzoqLmjaY1fr4IvLGs2DghuyrpiE8CmXjDwUdemOGI0fWmpR+2xSxs
YsdJepHvhElUnj0trBciTsrrV5eUo99T3ZN0/Fk25lG69f6fdA==
=+Vib
-----END PGP SIGNATURE-----

--nextPart3992894.9ob9zZpZbj--




--===============0446864373==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

LS0gCmNhaXJvIG1haWxpbmcgbGlzdApjYWlyb0BjYWlyb2dyYXBoaWNzLm9yZwpodHRwczovL2xp
c3RzLmNhaXJvZ3JhcGhpY3Mub3JnL21haWxtYW4vbGlzdGluZm8vY2Fpcm8=

--===============0446864373==--