It works. Mostly. Sort of. Only on Windows fonts. Sometimes it
randomly refuses to render glyphs (try `х`, that's not a latin ex).
I'm not really sure why, the logic seems right.
Why do we have a homegrown TTF parser anyway? It's kind of awful.
It breaks on any slightly unusual input. It plows through UTF-16BE
font names like a nuclear-powered steamroller. It outright ignores
composite glyphs (is that why it's broken this time?). The kerning
is seizure-inducing. It ignores any characters outside BMP by design.
Maybe we should just replace it with freetype.
This removes the arbitrary 64 byte restriction (which effectively
limits us to as little as 16 Unicode characters with CJK encodings),
makes classes smaller, and is easier to use.
As a consequence of making the length of all ex-NameStr fields
unbounded, all functions that returned a buffer derived from those
were changed to return std::string. Then, functions that are
contextually similar to the ones described above were changed
to return std::string. Then, functions that now happened to mostly
take an std::string argument converted to a C string were changed
to accept std::string.
This has produced a bit of churn, but is probably for the better.
Now it is possible to give non-ASCII names to groups
as well as see non-ASCII filenames of imported files.
In the future this makes localization possible.
This works for LTR languages, such as European and CJK,
but not RTL such as Arabic. Does Arabic even exist in
monospaced form? I have no idea.
After this commit, SolveSpace can robustly handle non-ASCII filenames
on every OS. Additionally, on Windows, filenames longer than 260
characeters can be used, and files on network shares can be opened
directly, without mounting them as a network drive.
After this commit, SolveSpace always uses UTF-8 strings internally
(represented as char* and std::string) on every OS, for everything:
UI labels, paths and user input. OS X always uses UTF-8; on Windows,
strings are converted at boundary; and on Linux/BSD/etc SolveSpace
refuses to start unless the current locale is UTF-8. This will
negatively affect literally no one.
This commit does not bring forth any user-visible improvement yet;
in order to correctly handle Unicode in filenames, it is still
necessary to change the fopen calls to _wfopen on Windows.
After this commit, SolveSpace deals with paths as follows:
* Paths are generally treated as opaque platform-specific strings.
This helps on Linux, because paths on Linux don't have any
specific encoding and it helps to avoid any operations on them.
* The UI in some places wants to get a basename. In this case,
the newly introduced PATH_SEP is used. This allows to treat
backslash as a regular character, which it is on Linux and OS X.
* The only place where any nontrivial operations on paths are
performed is the g->impFile/impFileRel logic.
Specifically, when saved, g->impFile always contains an absolute
path with separators of the current platform, and g->impFileRel
always contains a relative path with UNIX separators. This allows
to treat backslash as a regular character.
Old files will contain g->impFileRel with Windows separators;
these are detected by looking for a drive letter in g->impFile
and in that case mapping Windows separators to UNIX ones.
There is no need to treat UNIX separators (forward slashes) in
any special way on Windows because there is no way on Windows,
not even via UNC paths, to create or address a directory entry
with a forward slash in its name.
What do we gain from this? Several things.
* First, usage of PATH_MAX (the POSIX constant) is eliminated.
PATH_MAX is actually a lie; Linux and OS X (and probably other BSDs
too) do not have an actual path length limit. Linux claims 4096,
OS X claims 1024, but it is trivial to construct paths that are
longer.
* Second, while Windows does enforce a limit of MAX_PATH (the Win32
constant) for its ASCII functions, the Unicode variants, when
used with UNC paths, do not have this restriction.
The capability to use UNC paths is useful by itself, as it allows
to access files on network shares directly.
* Third, representing paths as std::string will make it easier to
interoperate with *W WinAPI functions later.
On Windows, freeze.{cpp,h} was factored into w32main.cpp.
The old implementation was too redundant and leaked registry
key handles.
On all platforms, Cnf* functions now use std::string.
This simplifies code everywhere, but will be particularly useful
when the Windows port switches to the *W WinAPI functions.
This is necessary to store non-POD classes in these containers.
Note that List and IdList do not use MemRealloc anymore;
this is necessarily (slightly) less efficient, but is the right
semantics, as you cannot just move non-POD types, e.g. std::string,
around in memory. All STL containers provide the same guarantees
and share the performance hit.
The slowdown is mostly mitigated by moving the contained objects,
so that no additional heap allocations or copies occur beyond
that of the object itself.
This will allow us to use non-POD classes inside these objects
in future and is otherwise functionally equivalent, as well
as more concise.
Note that there are some subtleties with handling of
brace-initialization. Specifically:
On aggregates (e.g. simple C-style structures) using an empty
brace-initializer zero-initializes the aggregate, i.e. it makes
all members zero.
On non-aggregates an empty brace-initializer calls the default
constructor. And if the constructor doesn't explicitly initialize
the members (which the auto-generated constructor doesn't) then
the members will be constructed but otherwise uninitialized.
So, what is an aggregate class? To quote the C++ standard
(C++03 8.5.1 §1):
An aggregate is an array or a class (clause 9) with no
user-declared constructors (12.1), no private or protected
non-static data members (clause 11), no base classes (clause 10),
and no virtual functions (10.3).
In SolveSpace, we only have to handle the case of base classes;
Constraint and Entity have those. Thus, they had to gain a default
constructor that does nothing but initializes the members to zero.
After this change, SolveSpace does not contain nonfree assets.
Additionally, Perl is not required for the build.
Note that in the US, case law suggests that copyright does
not apply to bitmap fonts:
http://www.renpy.org/wiki/renpy/misc/Bitmap_Fonts_and_Copyright
Nevertheless, it was prudent to replace the asset with something
that is unambiguously free.
Almost all construction requests are lines, and allowing to
draw them as construction obviates the need to select them one
by one afterwards to convert them. Also, it removes the "not closed
contour" error message, which is a nice usability improvement.
This is equivalent to adding a constraint, then making it a reference.
The benefits are that:
* it's quicker;
* it avoids having an over-constrained system, with an associated
angry red flash and a regeneration delay.
The latter in particular is a very substantial usability improvement.
The reference distance command is useful most of the time,
but the reference angle one is also added for consistency.
The main benefit is that std::swap will ensure that the type
of arguments is copy-constructible and move-constructible.
It is more concise as well.
When min and max are defined as macros, they will conflict
with STL header files included by other C++ libraries;
in this case STL will #undef any other definition.
As a side effect, zlib and libpng are now git submodules,
based on their respective official git repositories.
This is necessary, because MinGW has a different ABI and
it cannot use the prebuilt binaries built by MSVC.
The submodules are also used for Windows, for several reasons:
* to allow 64-bit builds;
* to allow using newer MSVC, which doesn't like the prebuilt
libraries;
* to keep the libraries updated.
Some extra code is necessary to determine that the back faces
should not be drawn in red for transparent solids. It is expected
that the user will first ensure that the shell is watertight
and then set the opacity; back faces are still drawn if
the opacity is exactly 1.
The savefile format is changed backwards-compatibly by stashing
the alpha value in uppermost byte of 4-byte hex color value
in Surface and Triangle clauses. The existing files have 00
in the high byte, so RgbColor::FromPackedInt treats that
as "opaque".
This is done specifically targeting the case where an assembly
initially made on Windows is transported to an *nix machine.
On *nix, the paths will be already saved with /, and correctly
read on Windows. On Windows however / is not a first-class separator,
in particular it cannot be used in UNC-style paths \\?\ (which
are the only paths that work with Unicode).
See also:
http://msdn.microsoft.com/en-us/library/aa365247.aspx
EvilSpirit
whitequark
ruevs
William D. Jones