BlinkGTK 1.2.0-build3 Release Notes

Released: 2026-08-08 / Chromium: 151.0.7922.71 / Language: English | 日本語

The rendering engine moves to Chromium 151. This release brings a cluster of changes
that act directly on Japanese typography. In particular, documents that use emphasis marks
in vertical writing mode will lay out differently.

New in build3

GPU rendering now works with a single setting

One environment variable switches to the GPU path.

BLINKGTK_GPU_MODE=egl ./myapp

No application changes are needed. Scrolling stays light even in long
vertical-writing documents, and it is noticeably faster than CPU rendering.

Until now this path needed four separate things to be set up (GTK4 integration,
a manual viewport, the device scale, and the receiving widget) — and the only
place that did so was our development browser, which is not part of the
distribution. Applications had no way to know, so setting
BLINKGTK_GPU_MODE=egl left the window blank. All of that setup now happens
inside the engine.

It requires a real GPU and a Wayland-EGL-capable driver. On some machines CPU
rendering is still faster, so try it on your own hardware.

Resizing no longer shows text twice

While a window was being resized or made fullscreen, the previous frame and the
new one could appear on top of each other. In vertical writing, line positions
are everything, so shifted lines read as broken typography.

Until the new frame is ready, the previous frame is now shown at its own size
rather than stretched. Nothing moves, so nothing appears doubled. A margin is
visible during the transition.

You can choose the behaviour:

Rendering is now checked automatically on every engine update

Each time the underlying Chromium was updated, the GPU path tended to regress to
a blank or shrunken picture. There is now a check that detects both from logs
alone — no display required — and it is a required step when updating.

New in build2

The engine reports its real version

navigator.userAgent now reflects the engine actually in use.

before: BlinkGTK/0.1.0 Chrome/143.0.0.0
now:    BlinkGTK/1.2.0 Chrome/151.0.0.0

It used to be a fixed string that never followed engine upgrades, so the UA
claimed a version eight majors old. That is not "claiming an old version to
be safe" — it is the kind of error that makes sites decide a feature is
absent when it is present. Pages that branch on version detection could
behave differently.

The version now comes from the same single source as
blink_gtk_get_version() / blink_gtk_get_chromium_version(), so the UA and
the C API can no longer disagree.

Vertical layout metrics readable from JavaScript

For vertical multicol layout, page JavaScript can now read the values the
engine actually used, instead of inferring line pitch and column boundaries
from client rects.

window.__blinkgtk.verticalFlowMetrics(element)
// -> { stride, originX, contentWidth, columnCount, lineCount, generation,
//      lines: [{ inlineSize, blockOffset, columnIndex, hasHanging }] }

columnIndex is the engine's own fragmentainer index, not the result of a
coordinate comparison. A line sitting exactly on a boundary cannot be assigned
to the wrong column.

Requires --enable-blink-features=CJKVerticalColumnFragmentation at startup.
When it is off, window.__blinkgtk is not created at all, so typeof works as
a feature check.

Current limitation: the element you pass must itself be both vertical
writing mode and a multicol container. A two-layer structure — a horizontal
multicol outer box with a vertical inner box — returns null. Support for
that shape lands in the next build.

Documentation samples work as written

28 C / C++ samples in the bundled documentation did not display a page when
written exactly as shown. g_application_run() does not run Chromium's browser
main loop; the code compiles and starts, which is what made it hard to notice.

They are corrected — including the QUICKSTART that readers see first — and a
gate now detects the pattern.

GError *error = NULL;
g_application_register(G_APPLICATION(app), NULL, &error);
g_application_activate(G_APPLICATION(app));
int status = blink_gtk_run_main_loop();   /* not g_application_run() */

The local emphasis-mark patch is gone

The emphasis-mark patch carried in the v1.1 series has been removed, and
behaviour is now whatever Chromium 151 does. Upstream solved the same
problem in 151, so carrying a local change no longer helped. See
"Emphasis marks no longer thicken the line pitch" below.

What you can do now

Emphasis marks no longer grow the line pitch

Until now, a line carrying emphasis marks (boten) grew taller than the rest. JIS X 4051
and JLReq require emphasis marks to sit in the leading without changing the line pitch, so
the behaviour was out of step with the standard.

151 resolves it. Measured on a 151 build: vertical writing mode, font-size: 16px,
text-emphasis-style: sesame, reading the actual paragraph pitch.

With room in the leading there is no growth at all. Without room, growth shrinks from
+9.00 to +2.00.

Vertical documents that use emphasis marks heavily may end up with fewer pages.
The change is for the better, but check anywhere you depend on fixed page numbers.

Ruby overhang behaves as specified

ruby-overhang is on by default. It controls how far ruby text may extend over
neighbouring base characters when the annotation is longer than what it annotates, and
none is available to forbid overhang. This is the engine meeting JLReq head-on on how
ruby may be placed.

Automatic spacing is no longer perturbed by ruby

Automatic spacing between Japanese and Latin text (text-autospace) is no longer thrown
off by ruby text, reducing uneven letter spacing in annotated body text.

Line breaking no longer crowds before an open tag

In markup such as 日本語 <span>語</span>, a break is now allowed after the space,
reducing breaks landing in unintended places.

One generation forward on web standards

Between Chromium 150 and 151, 44 features became enabled by default, including logical
corner properties, text-fit, focusgroup, and momentum information on wheel events.
A version-by-version breakdown is in
Chromium 147 → 151.

What to check when upgrading

Some upstream changes alter behaviour.

In vertical writing, a paragraph ending in a closing bracket can leave its line half empty

This is a Chromium defect. In vertical writing, when a paragraph contains an inline
element (<span>, <ruby>, …) and ends with a fullwidth closing bracket
(」』）〉】｝］), line boxes within a particular 8px band hold only about half the
characters they should. With text-align: justify the letter advance then roughly
doubles, which is what makes it visible.

Reported upstream — crbug 542686223.

There is no workaround that keeps the punctuation trimming.
text-spacing-trim: space-all removes the symptom but switches the trimming off
entirely. trim-start only shifts the affected band by 8px; it does not avoid it.

Requirements

• Linux (Wayland)
• GTK 4.6 or later / GLib 2.70 or later
• Embedding applications must link the PartitionAlloc allocator shim directly.
  Using pkg-config --libs blinkgtk-0.1 includes it automatically.
  This requirement continues on 151 (verified on this build).
  See the integration guide.

Switches for diagnosis

Environment variables useful for isolating a problem. Do not set these in normal use.

About the version number

1.2.0 is the product version; it reflects the Chromium baseline moving from 150 to 151.
build1 counts rebuilds within that product version. When reporting a defect, please
include the build number.

The 0.1 in package names and paths (libblinkgtk-0.1.so.0 and so on) is the API version
and is independent of the product version — the same convention as GTK4's gtk-4.0.

Contact

• Defects and requests: https://github.com/daisy19gnu/blinkgtk-dist/issues
• Enquiries: contact@blinkgtk.org