| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Two variants, as astral characters require an additional pair of
hex digits.
|
| |
|
|
| |
Thus ensuring that the UCS FM tests exercise the relevant code
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This file is broken in a number of ways:
* It contains garbage content that does not form valid
glyph name specifiers
* It contains garbage directives
* It tries to define more than 256 glyphs (which is not
supported by non-UCS FontManagers)
The latter point above uncovered a bug in the umap sanity checking
where it failed to properly count the number of glyph indices
being defined by the Encoding file.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This exposed a failure to clean up any FontManager error occurring
when attempting to load this kind of font. Additionally, it also
exposed a failure to initialise the umap count in an internal
structure. This was probably harmless in reality, but caused the
test to fail.
|
| |
|
|
|
| |
These now take a configuration file defining the available
encodings for each face and setting the expected number of umaps.
|
| | |
|
| |
|
|
|
|
| |
This will cause the second initialisation attempt to load the
cache file. In doing so, we discover that cache loading on
non-32bit platforms didn't work -- fix that, too.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The Font_ScanString mock was deficient here, refusing to return
the split point in the x_to_offset case. Additionally, the tests
themselves were passing entirely the wrong units into the API.
Further, the Font_EnumerateCharacters mock needed updating to
ensure that all the codepoints used in the tests have glyphs
defined (as otherwise, we fall down the missing glyph path).
Given all of this, it's somewhat miraculous these checks passed.
|
| |
|
|
|
|
|
| |
This exercises the broken Font_EnumerateCharacters workaround.
Ensure tests don't trample on each other by having them run in a
temporary directory.
|
| | |
|
| |
|
|
|
| |
Implement XOSFS_CanonicalisePath and XFont_ScanString and
introduce a new test that uses them.
|
| |
|
|
|
|
| |
It is now possible to initialise a test harness which mimics the
behaviour of the various versions of the FontManager we support.
Rename the simple test to reflect its new purpose.
|
| |
|
|
|
|
| |
Mock out every OS call made by the library (they all return an
unimplemented error for the timebeing). Add a trivial test case
that verifies that rufl_init() fails.
|
| |
|
|
|
|
| |
Compiling for other platforms has its benefits. The first of which
is x86_64 gcc rightly complaining that the buffer to receive the
error message is too small. Make it big enough.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Add a verbose flag to rufl_dump_state() and use it to control
whether to dump the individual unicode maps generated when using
a non-UCS Font Manager.
Change rufl_test to not dump this state (ordinarily, anyway) as
it is generally uninteresting and highly verbose.
|
| |
|
|
| |
Selectable via the menu, like everything else.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
As we introduce support for discovering and rendering astral
characters, ensure that we pass UCS-4 to the relevant Font Manager
APIs and extend our replacement hex code generation to emit
6 digits for codepoints outside the Basic Multilingual Plane.
This has necessitated a change to the API of the callback function
provided to rufl_paint_callback(). Where, previously, a 16 bit
UCS-2 string was exposed, we now expose UCS-4.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a non-Unicode world, a (non-Base) encoding may define glyphs for
up to 256 character codes. Ensure that at most 256 Encoding file
entries are used (as, otherwise, the character code will overflow).
In particular, if symbol fonts created for the Unicode Font Manager
(which does not have a 256 character limit for an encoding) are
installed on a non-Unicode-capable system, only the first 256
glyphs in the font are accessible although the Encoding file may
have more than 256 entries.
Note, however, that the first 32 character codes will never be used
as they are considered control codes. Thus, at most 224 usable
characters may be defined.
A further wrinkle is that glyph names may map to multiple Unicode
codepoints, thus consuming multiple slots in the unicode map (which
itself has a fixed size of 256 entries). Thus, it is technically
possible for the unicode map to further limit the number of usable
characters in a font to fewer than 224.
However, unless the font is particularly baroque, this isn't a
problem in the real world, because there are only 12 glyph names
which map to more than one Unicode codepoint (they map to 2, each,
for a total of 24 unicode map entries, if they're all present).
Thus, to run out of space in the unicode map, you'd need a font
which defines at least 4 of those glyphs twice (and defines the
others once, and also defines known glyphs for every other
character code).
Fixes #2577.
|
| |
|
|
| |
svn path=/trunk/rufl/; revision=14012
|
|
|
The python module (and associated make runes) need some love (as does non-GCC building with the core buildsystem in general)
svn path=/trunk/rufl/; revision=9792
|
