When SolveSpace tries to display an Unicode code point (e.g. U+EA00 )
that does not exist in the embedded vector font (unifont.hex.gz) it hangs
in an endless loop in
`const BitmapFont::Glyph &BitmapFont::GetGlyph(char32_t codepoint)`.
The reason is that the binary search through the text file unifont-8.0.01.hex
that does the "lazy loading" of glyphs does not end.
Here is a short excerpt from the file:
```
D7FE:00007FFE63866DF66DEE6DDE63DE7FFE7FFE61866FBE638E6FBE6F867FFE0000
D7FF:00007FFE63866DF66DEE6DDE63DE7FFE7FFE61866FBE638E6FBE6FBE7FFE0000
F900:0080108810881FF8100800007FFE00000FF008100FF00810042002447FFE0000
F901:00047FFE008010841FFE10841FFC10841FFC10840880050003000CC0703E0000
```
When searching for `0xEA00` after some iterations of the while loop
2450010bbf/src/resource.cpp (L567)
both `first` and `last` end up pointing to F900. After that on each
consecutive iteration of the loop `last` ends up pointing to the LF (0x0A)
just before F900
2450010bbf/src/resource.cpp (L585)
and then `mid` ends up back on F900 here
2450010bbf/src/resource.cpp (L570)
and this will repeat enlessly.
The solution is to do
```
first++;
```
here
2450010bbf/src/resource.cpp (L591),
which will make `first==last` and change whe while loop contition to `while(first < last) {` thiw will
allow the while loop to exit.
Tested with
- 0xEA00 - non existent, not found in 16 iterations.
- 0xF900 - exists but takes exactly 16 iterations of the binary search to finish
- 0x0000 - found in 16 iterations
- 0xFFFD - the replacement Unicode code point for non-existing glyphs. Also the end of the font.
- 0xFFFFF - a codepoint beyond the end, not found and does not cause an exception
The lazy parsing of the vector front was introduced here.
645c2d90acFixes#1150
If the main window is not high enough allow the default 32 pixel padding
between the menu bar and the toolbar to shrink down to zero.
This allows the main window height to be a minimum of 688 pixels (on
Windows 10) so it is possible to capture 720P video tutorials.
Fixes#1130
Re-creating the edge release for every push
to master creates many superfluous release notifications.
Stop creating those releases and provide users with direct
links to the workflow artifacts instead via the
nightly.link GitHub app (https://github.com/apps/nightly-link).
Fixes#1103
The snaps use git describe to determine
their grade (stable/devel). Fetch the tags to
make this possible.
Point users to the official release in the stable channel in README.md.
* mac: Support for pan, zoom and rotate trackpad gestures
Currently SolveSpace is nearly unusable on a mac if you only have a
buttonless trackpad and not a mouse, because there's no way to pan
(ie right-click-drag) or rotate (ie middle-click-drag). You can zoom,
but only by using two-finger-drag up and down, which ends up getting
interpreted as a scrollwheel event.
This change makes the app behave much more like any other mac app, by
adding 2-finger-drag pan gesture support and pinch-gesture zooming, and
3D rotate using shift-2-finger-drag.
I've also added support for the rotate two-finger trackpad gesture,
which rotates directly around the screen Z axis (rather than in all 3
dimensions) which is actually something I've found myself wanting to do
with the mouse but afaik there's no equivalent way of achieving that.
While I was there, I fixed a bugette in convertMouseEvent which was
incorrectly translating the NSEvent coordinates, and then fixing up the
fact that the sign of the y-coordinate was wrong as a result. Using the
convertPoint API correctly means that fixup is not required because
convertPoint handles it for you.
* Don't do trackpad gestures on anything except the toplevel window
* mac: Fix non-functional scrollbar on text window
Which has not worked quite right since the last major refactor.
* Don't pass right-button drags to the toolbar
This improves the behaviour of trackpad pan/rotate on mac which uses
simulated right-button events.
* Don't pass cmd/ctrl modifier through on trackpad pan/rotate MouseEvents
By no longer always returning NSTerminateCancel in
applicationShouldTerminate.
And implement applicationWillTerminate to ensure the cleanup code in
SolveSpaceUI::Exit() is always called.
By making IsForcedToMesh() always return true for STL link groups,
rather than trying to set forceToMesh=true during the import phase.
STL link groups are now always shown as "model already forced to
triangle mesh" in the details screen, but also (unlike when the model
is forced to mesh by a parent group) show the '∆' icon in the group
list.