Previously, alignment did exist, but it only changed whole text block
position in relation to a fixed point. This was later renamed to "Anchor".
Now it correctly aligns each line of text. Alignment works with newline
character and word wrapping.
Currently newline characters can't be entered directly, but this should
be resolved soon.
To keep existing anchoring feature, new DNA fields are added and
values from old alignment are copied there.
This PR is part of bigger change [1], and originally I expected to
implement this feature at later stage. But the design called for drawing
text character by character, which would mean, that I would have to
rewrite text alignment anyway.
To render the text, a struct is built, where position and width of each
character is stored. In addition, width of each line is stored. This allows
to implement proper text alignment feature, instead of existing
anchoring. Text is then drawn character by character in a loop.
There are some small differences in text rendering, since this is only
approximation of how BLF library draws glyphs, but it is very close.
For text bounbox, `BLF_boundbox()` is used on per line basis,
because some fonts do not use their full height and this information
is not available on VSE side.
[1] https://projects.blender.org/blender/blender/issues/126547
Pull Request: https://projects.blender.org/blender/blender/pulls/126660
This PR has very slight corrections to text cursor placement in input
widgets. The most important is a check for the situation where the
right edge of the current character can be greater than the left edge
of the next character. This can happen for some thin characters before
a space. Otherwise the code assumes RTL direction and gives an
incorrect placement. This also slightly tightens the position when at
the start of string, just after a space, or at end of the string.
Pull Request: https://projects.blender.org/blender/blender/pulls/127662
For the times we need to obtain the bitmap of an SVG icon, send these
through the new theme coloring callback if they are multi-color. This
removes some code duplication by adding a new function that gets an
imBuf from SVG Icon. This allows, for "About" logo, Dialog icons, and
file system icons the optional ability to use a single SVG source file
that works as both monochrome (themed by text color) or multicolor with
internal parts themed.
Pull Request: https://projects.blender.org/blender/blender/pulls/126215
Allow color SVG icons to have their fill colors modified by theme
colors using a callback. This is done just before rasterization so
only happens once per requested size, before these are cached for
reuse.
Pull Request: https://projects.blender.org/blender/blender/pulls/125146
When we draw SVG icons we have an optional argument that specifies to
treat it as multicolor. This PR allows doing the same thing when
requesting a bitmap from an icon. This is only currently done for
Dialog boxes and the About screen. The purpose of this isn't really
to allow multicolor dialog icons, but to get to the point where a
single SVG source file could be used as monochrome (changing the one
color with text color) or multi-color (changing internal colors with
themes) without needing multiple copies of the source file
Pull Request: https://projects.blender.org/blender/blender/pulls/126193
This PR corrects some mistakes in the conversion between RGBA bitmaps
created when rasterizing SVG icons and the monochrome coverage maps
when displaying these in a single color. This only occurs when we need
a bitmap from an icon for About screen and for dialogs. The bitmap
from NanoSVG is already premultiplied so don't do it again. When
converting from coverage map to RGBA use map value for all components
rather than FFF for colors. When converting to coverage map from RGBA
use perceptual grayscale level of color, not just alpha value.
Pull Request: https://projects.blender.org/blender/blender/pulls/126192
When we use icons that are multi-color, like for Tool icons, we'll
still need the ability to change their alpha at runtime. We do this
for hover effects, and as a theme setting.
Pull Request: https://projects.blender.org/blender/blender/pulls/126063
Slightly improved sub-pixel centering of icons within their bounds. This
also adds a minimum (negative) for the offsets for the future case of
icons that require a design that overflows the design grid. Not just
that that have non-square proportions but that also need to be maximum
height or width of the design grid. These should not center themselves
but be anchored at the specified location.
Pull Request: https://projects.blender.org/blender/blender/pulls/125844
This is visible in VSE text strip "box" and "outline" options at least.
For some fonts (mostly script/cursive type) BLF_boundbox function
was calculating horizontal bounds purely from pen position and
advance to the next character position. But the actual glyph can extend
beyond the advance distance.
Curiously, blf_font_boundbox_foreach_glyph (used by
blf_str_offset_from_cursor_position and blf_str_offset_to_glyph_bounds)
was already doing the correct thing and taking glyph horizontal bounds
into account.
Pull Request: https://projects.blender.org/blender/blender/pulls/125363
Size icons to subpixel precision to give slightly better results when used
with fractional resolution scales.
---
This change is very subtle. So you might have to trust me or get your reading glasses on...
Our icons are designed for small sizes. When the Blender resolution scale is set to exactly 1.0 then the icons are aligned perfectly to a 14x14 grid and features like lines are exactly one pixel wide. So these one-pixel wide lines are perfectly aligned to the pixel grid. Change the scale to 2.0x and they also align perfectly, just with lines that are two pixels wide.
But what happens at 1.25x scale? Now the icon is 17.5 pixels and lines in it are a pixel and a quarter wide . The best that can be is a solid pixel and one next to it that is quarter-opacity. But it can get worse than that as it could potentially touch three adjacent pixels.
Our old icon code took an icon bitmap that was rendered larger and scaled it into the desired size. Because this was done by the opengl shader, this scaling was done to subpixel size. So at 1.25 scale you got an icon that was 17.5 pixels.
The new icon code is truncating the sizes to integer before rendering. I thought this was best, but I was wrong.
The following image has three rows. The top is the old icon code, with UI scale from 1.0, 1.25, 1.5, 1.75, and 2.0. The second row is current code. The third is with this PR:
The first and last columns are identical, obviously because the design perfectly fits the pixel grid.
The left green area, at 1.25 scale, current code is forcing the design into an integer size, while (bottom) gives a more pleasing result as it is properly spread over 17.5 pixels.
The right green area is more interesting. With both the old code and new code, the 1.75 pixel wide line is spread over three pixels. The PR nicely spreads it over two pixels.
Hard to tell; Just squint. This is just very slightly more pleasing rendering of icons.
Pull Request: https://projects.blender.org/blender/blender/pulls/124436
Only when the user changes the UI font to one that does not have a
variable weight axis, update the text style weights to match the font's
design weight. So if changing to an old-school font that has a fixed
weight, for example bold, also update UI Text Style weights to match
so everything looks as designed and expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/124074
On rare occassions we need to turn an icon into a bitmap rather than
just draw it. For example, File Browser needs the bitmaps of the large
folder and file icons for use while dragging list items. This PR just
adds functions for this conversion from cached glyphs, and then uses
them to load the gSpecialFileImages "prv" icons so we no longer have
to include these in an embedded PNG file.
Pull Request: https://projects.blender.org/blender/blender/pulls/123749
Distribute our UI icons as separate SVG files in a folder in the
Blender installation. Rasterize each only when requested at the exact
size needed, and then saved in the text glyph cache for later uses.
Pull Request: https://projects.blender.org/blender/blender/pulls/121718
Add a separate function that calculates text selection box positioning
given a string's selection start and end offsets. Moves this to a
better place and allows to have more complex boxes in future when we
might have multi-line and/or multi-directional text input.
Pull Request: https://projects.blender.org/blender/blender/pulls/121448
With Aras's recent changes in #121383, our text shader now supports
outline shadows, which gives a result that has more contrast than can
be achieved with BLF_draw_default_shadowed. This removes that function.
Pull Request: https://projects.blender.org/blender/blender/pulls/121676
Overlay texts were previously drawn with two sets of shadows:
- 3px blur,
- 5px blur, slightly offset
But since the shadow color was always set to black, it was still
causing legibility issues when the text itself was dark (set
via theme for example).
This PR adds a new "outline" BLF text decoration, and uses that
for the overlays. And it picks text/outline color depending
on the "background" color of the view.
Details:
- Instead of "shadow level" integer where the only valid options
are 0, 3 or 5, have a FontShadowType enum.
- Add a new FontShadowType::Outline enum entry, that does a 1px
outline by doing a 3x3 dilation in the font shader.
- BLF_draw_default_shadowed is changed to do outline, instead of
drawing the shadow twice.
- In the font shader, instead of encoding shadow type in signs of
the glyph_size, pass that as a "flags" vertex attribute. Put
font texture channel count into the same flags, so that the
vertex size stays the same.
- Well actually, vertex size becomes smaller by 4 bytes, since turns
out glyph_mode vertex attribute was not used for anything at all.
Images in the PR.
Co-authored-by: Harley Acheson <harley.acheson@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121383
BLF_buffer was trying to accept "how many colors channels in output
image?" argument and doing math with it, but in the lowest level code
was always writing out full 4 channels for each pixel.
All the call sites would ever call it with argument of 4 however, and
that is why no one noticed the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/121630
These are not fully supported, users who load these will not be able
to access all the faces within the TTC/OTC.
Existing uses of TTC/OTC won't be blocked, these are just not shown as
supported fonts in the file selector. Addresses #44254.
Ref !121060
I added code in #120673 that included a line that is a no op. This
removes that code, replacing it with a comment to my future self why
I shouldn't do a particular thing that could break in an unlikely
state that won't happen for a while.
Pull Request: https://projects.blender.org/blender/blender/pulls/120728
For our built-in fonts (in our stack) we specify the Unicode page
coverage that they support, to avoid loading fonts unnecessarily to see
if they have a particular character. This way we skip over fonts to
get to symbols, etc. With our CJK (Chinese, Japanese, Korean) font
though we are using the supplied coverage bit values, which includes
more than we want. We only want to load this font for CJK-related pages
to ensure that we use more tailored fonts for other specific languages
and uses later in the font stack.
Pull Request: https://projects.blender.org/blender/blender/pulls/120676
When we iterate through glyph bounding boxes, we should ignore
combining characters, those without an advance. These types of
characters are placed over top of others, like for diacritical marks.
We never have a need to consider these, only for the parent glyph.
Otherwise mouse insertion of text cursor can occur at the wrong
location, at the edge of a diacritical mark.
Pull Request: https://projects.blender.org/blender/blender/pulls/120675
BLF function blf_str_offset_from_cursor_position returns the character
offset in a string given a horizontal cursor position. It currently has
no early exits, but can do so for no string or empty string. For negative
position values (so left of the string), do not exit out with zero but
instead act as if it were zero to ensure we test against the first glyph,
which might not be part of the character.
Pull Request: https://projects.blender.org/blender/blender/pulls/120673
Move into own BLF function, code that returns a text cursor (caret)
position given a string offset. This code is currently just in
interface_widgets.cc but should be a separate BLF function.
Pull Request: https://projects.blender.org/blender/blender/pulls/120622
Remove all BLF "_ex" versions of functions by using default arguments.
These functions only differ by having an optional argument that can
return extra details about the result of the operation. This PR just
make these part of the main function as optional arguments with default
values - all nullptr.
Pull Request: https://projects.blender.org/blender/blender/pulls/119994
Now that all relevant code is C++, the indirection from the C struct
`GPUVertBuf` to the C++ `blender::gpu::VertBuf` class just adds
complexity and necessitates a wrapper API, making more cleanups like
use of RAII or other C++ types more difficult.
This commit replaces the C wrapper structs with direct use of the
vertex and index buffer base classes. In C++ we can choose which parts
of a class are private, so we don't risk exposing too many
implementation details here.
Pull Request: https://projects.blender.org/blender/blender/pulls/119825
