This uses the per glyph width to determine if the glyph is actually
present in the font, and not just inside the range the font can covers
This means that characters that are in the font's range but that are
missing a glyph will show up as the missing character glyph instead of
being invisible.
This replaces the glyph width spinbox in the font editor with a
checkbox when editing fixed width fonts that indicates if the
currently selected character's glyph is present in the edited font
(For variable width fonts a non zero width implies presence)
This commit also changes the background color of glyphs in the glyph
map based on the presence of each specific glyph in the font.
Since we were always saving the glyph widths array to the font file, we
now also always load it, even on (which also simplifies the logic a bit)
fixed width fonts. We also set it initially to 0 instead of the default
fixed width, which allows us to use it to check for glyph presence in
both fixed width and variable width fonts.
This warning informs of float-to-double conversions. The best solution
seems to be to do math *either* in 32-bit *or* in 64-bit, and only to
cross over when absolutely necessary.
Since we first check the winding number and only then update it, fills
for "Rectangle-like" (made up of 2 parallel segments) paths would draw
nothing when filled by NonZero winding rules. (Fix by alimpfard)
I hereby declare these to be full nouns that we don't split,
neither by space, nor by underscore:
- Breadcrumbbar
- Coolbar
- Menubar
- Progressbar
- Scrollbar
- Statusbar
- Taskbar
- Toolbar
This patch makes everything consistent by replacing every other variant
of these with the proper one. :^)
This commit makes the user-facing StdLibExtras templates and utilities
arguably more nice-looking by removing the need to reach into the
wrapper structs generated by them to get the value/type needed.
The C++ standard library had to invent `_v` and `_t` variants (likely
because of backwards compat), but we don't need to cater to any codebase
except our own, so might as well have good things for free. :^)
A "Tray" is a sunken container area for widgets. The first intended
client of this style is the GUI::FilePicker's common locations frame.
Thanks to @nvella for coming up with the term "Tray" :^)
As per the PNG specification: "Filter method is a single-byte
integer that indicates the preprocessing method applied to the
image data before compression. At present, only filter method 0
(adaptive filtering with five basic filter types) is defined."
As per the PNG specification: "For all x < 0, assume Raw(x) = 0 and
Prior(x) = 0. On the first scanline of an image (or of a pass of an
interlaced image), assume Prior(x) = 0 for all x."
This prevents the undefined behaviour that would come up as a result of
doing so. (For example: opening "infinite" devices like /dev/full will
result in an infinite loop until exhaustion of memory)
PNGs use deflate with zlib, however we were just skipping the zlib
bytes and then piping it into deflate decompressor. Since we have a
zlib decompressor, lets use that instead.
This has the added benefit of extra error checking.
This patch begins the transition away from the global menu towards
per-window menus instead.
The global menu looks neat, but has always felt clunky, and there
are a number of usability problems with it, especially in programs
with multiple windows.
You can now call GUI::Window::set_menubar() to add a menubar to
your window. It will be specific to that one window only.
This will be used by ImageData objects in LibWeb since the web spec
says these store colors in RGBA8888 order.
The only thing you can do with this format right now is blitting it
onto a BGRA8888 bitmap.
The previous names (RGBA32 and RGB32) were misleading since that's not
the actual byte order in memory. The new names reflect exactly how the
color values get laid out in bitmap data.
