GitLab

The OT spec says:

"When building a Unicode font for Windows, the platform ID should be 3 and the
encoding ID should be 1. When building a symbol font for Windows, the platform
ID should be 3 and the encoding ID should be 0."

We were ignoring the SYMBOL_CS entry before.  It's UTF-16/UCS-2 like the
UNICODE_CS.

Also, always use UTF-16BE instead of UCS-2BE.  The conversion was doing
UTF-16BE anyway.

Bug 26783 patch: unistd.h not exist on ms windows

Run the uninstalled fc-cache, not the installed one.

Remove dolt.  With libtool2, there's not much need for dolt.

Don't put entries for directories in the zip file. Fetch manpages from
correct place.

Use LIBT_CURRENT_MINUS_AGE instead of the undefined
lt_current_minus_age for the name of the DLL when generating the MS
style import library.

We only care about three properties in the arch:

  - endianness
  - pointer size
  - for 32-bit archs, whether double is aligned on 4 or 8 bytes

This leads to the following 6 archs (old name -> new name):

	x86    -> le32d4
	mipsel -> le32d8
	x86-64 -> le64
	m68k   -> be32d4
	ppc    -> be32d8
	ppc64  -> be64

It was unused.

Although they were static, I was still surprised that gdb was seeing
our variable "glyphs".  Not helpful.

Last night in between my dreams I also noticed that we support Unicode
values up to 0x01000000 and not 0x00100000 which I thought before.
This covers the entire Unicode range.

Protect cache against future expansions of FcLangSet (adding new
orth files).  Previously, doing so could change the size of
that struct.  Indeed, that happened between 2.6.0 and 2.7.3, causing
crashes.  Unfortunately, sizeof(FcLangSet) was not checked in fcarch.c.

This changes FcLangSet code to be able to cope with struct size changes.
And change cache format, hence bumping from 2 to 3.