Documentation · BlinkGTK

BlinkGTK 1.2.0-build2 Release Notes

Released: 2026-08-05 / 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 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.

Leading available Without marks With marks Delta
Yes (line-height: 2.6 = 41.59px) previous 41.59 44.09 +2.50
this release 41.59 41.59 0
No (line-height: 1.75 = 28px) previous 28.00 37.00 +9.00
this release 28.00 30.00 +2.00

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.

Change Impact
Emphasis mark layout Line pitch changes, so page and line counts can change
readyState of document.implementation.createHTMLDocument() The state right after creation now follows the specification
Nested popover hint Showing one nested now throws
getComputedStyle outside the flat tree Off by default
Sub Apps API Removed

Requirements

Switches for diagnosis

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

Variable Effect
BLINKGTK_GPU_MODE=software / egl Selects the rendering path
BLINKGTK_EMPHASIS_INLINE=0 Turns off in-leading placement of emphasis marks (for layout comparison)

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