Building True Vector PDF Export in the Browser with fabric.js
https://yft.design/
https://github.com/dromara/yft-design
Most browser-based design editors can export a PDF by taking a screenshot of the canvas and wrapping that bitmap in a PDF file. That works for quick previews, but it falls apart as soon as users need print-ready output: text is no longer selectable, shapes blur when zoomed in, file sizes grow quickly, and CMYK workflows are basically out of reach.
In YFT Design Pro, we built a client-side PDF export pipeline on top of Fabric.js and Vue 3 that can generate real vector PDFs directly in the browser. It supports text-to-path conversion, SVG path rendering, gradients, CMYK output, font subsetting, multi-page documents, and asynchronous export through Web Workers.
This post walks through how the system is structured and the engineering problems we had to solve.
High-Level Architecture
The export pipeline has four main layers:
User clicks "Export PDF"
|
v
useCanvasExport
orchestration layer
|
+--------------------+
| |
v v
Raster PDF Vector PDF
colorSpace = 0 colorSpace >= 1
| |
v v
Canvas -> JPEG PdfGenerator
embedded in PDF running in Web Worker
|
v
@yft-design/pdf-lib
custom pdf-lib fork
The responsibilities are split like this:
-
src/hooks/useCanvasExport.ts
Handles the export entry point, chooses the export path, starts the Worker, and reports progress.
-
src/extension/export/pdf/
Contains PdfGenerator, which walks through Fabric.js objects and converts them into native PDF drawing operations.
-
packages/pdf-lib/
A fork of pdf-lib with additional support for SVG path parsing, gradient shadings, CMYK helpers, and lower-level PDF operators.
-
src/worker/
Runs the expensive PDF generation work outside the main thread so the editor UI stays responsive.
Why There Are Two Export Paths
YFT Design Pro supports both raster PDF export and vector PDF export.
Raster PDF
When colorSpace = 0, each page is rendered to a 300 DPI JPEG and embedded into a PDF page:
for (const template of templates) {
const dataUrl = canvas.toDataURL({
format: 'jpeg',
quality: 0.95,
multiplier: dpi / 96,
})
const imageBytes = dataUrlToBytes(dataUrl)
const pdfImage = await pdfDoc.embedJpg(imageBytes)
const page = pdfDoc.addPage([pageWidth, pageHeight])
page.drawImage(pdfImage, {
x: 0,
y: 0,
width: pageWidth,
height: pageHeight,
})
}
This path is simple and fast. It is useful when users only need a visual PDF preview.
The tradeoff is obvious: the whole page is a bitmap. Text cannot be selected, vector shapes lose quality when zoomed, and the PDF is not suitable for professional print workflows.
Vector PDF
When colorSpace >= 1, every object on the Fabric.js canvas is traversed and rendered as native PDF content:
- Text can be drawn using embedded fonts or converted into vector paths.
- Shapes become PDF path operators.
- SVGs are parsed and rendered recursively.
- Images are embedded as image XObjects.
- Gradients become PDF shading dictionaries.
- RGB or CMYK color spaces can be selected depending on the export mode.
This path is slower, but it produces a real vector PDF.
Coordinate Conversion
Coordinate conversion is one of the first places where browser-to-PDF export gets tricky.
Fabric.js uses a screen coordinate system:
- Origin at the top-left corner
- Y axis goes downward
- Units are canvas pixels
PDF uses a page coordinate system:
- Origin at the bottom-left corner
- Y axis goes upward
- Units are points, where 1 inch = 72 points
The basic pixel-to-point conversion is:
private px2pt(px: number, dpi: number = 300): number {
return (px * 72) / dpi
}
At 300 DPI, a 300 px object becomes 72 pt in the PDF, which is exactly 1 inch.
The Y axis also needs to be flipped:
let baseY = this.px2pt(pageHeight - element.top)
let pdfY = baseY + this.px2pt(element.height * scaleY - localY * scaleY)
This sounds small, but it affects every feature: text baselines, grouped objects, SVGs, masks, rotations, gradients, and nested transforms.
Tracking the Current Transformation Matrix
PDF has a graphics state stack and a current transformation matrix, usually called the CTM. pdf-lib does not expose enough of that internal state for our use case, so PdfGenerator tracks its own CTM in parallel with the PDF content stream.
private currentCTM: [number, number, number, number, number, number]
private ctmStack: Array<[number, number, number, number, number, number]> = []
pushGraphicsState(page) {
this.ctmStack.push([...this.currentCTM])
page.pushOperators(pushGraphicsState())
}
popGraphicsState(page) {
this.currentCTM = this.ctmStack.pop()!
page.pushOperators(popGraphicsState())
}
Every transform operation is multiplied into the tracked CTM. That lets us keep nested groups, rotated elements, and recursively parsed SVG nodes aligned with the actual PDF drawing state.
Converting SVG Paths to PDF Operators
A major part of the vector export pipeline is converting SVG path data into PDF drawing commands.
SVG path string
"M10 20 L30 40 C50 60 70 80 90 100 Z"
|
v
parse commands and parameters
|
v
map each command to PDF operators
|
v
PDF content stream
"10 20 m 30 40 l 50 60 70 80 90 100 c h f"
The custom svgPath.ts implementation in our pdf-lib fork maps SVG commands to PDF operators:
| SVG command |
Meaning |
PDF operator |
M/m |
Move to |
m |
L/l |
Line to |
l |
H/h |
Horizontal line |
l |
V/v |
Vertical line |
l |
C/c |
Cubic Bezier |
c |
S/s |
Smooth cubic Bezier |
c with reflected control point |
Q/q |
Quadratic Bezier |
quadratic helper operator |
A/a |
Elliptical arc |
converted to cubic Bezier curves |
Z/z |
Close path |
h |
The hardest command is A/a, the SVG elliptical arc. PDF does not have a native arc operator with the same semantics, so each arc is approximated as one or more cubic Bezier segments.
The implementation follows the same general approach used by tools such as Inkscape’s SVG-to-PDF conversion:
function arcToSegments(rx, ry, rotation, largeArc, sweep, x1, y1, x2, y2) {
// Compute center, start angle, and angle delta.
// Split the arc into segments no larger than 90 degrees.
}
function segmentToBezier(cx, cy, th1, th2, rx, ry, sinPhi, cosPhi) {
const t = 4 / 3 * Math.tan((th2 - th1) / 4)
// Return cubic Bezier control points and endpoint.
}
The forked library exposes this as a higher-level API:
page.drawSvgPath(svgPathData, {
x: elementX,
y: elementY,
scale: scaleFactor,
rotate: degrees(angle),
color: fillColor ? rgb(r, g, b) : undefined,
borderColor: strokeColor ? rgb(r, g, b) : undefined,
borderWidth: strokeWidth,
})
Internally, it handles translation, rotation, scaling, and the SVG-to-PDF Y-axis flip.
Text: Embedded Fonts vs Text-to-Path
Text export has two modes.
In normal font mode, text is drawn with an embedded PDF font:
page.drawText(text, {
font: pdfFont,
size: fontSize,
color: fillColor,
})
In text-to-path mode, each glyph is converted into an SVG path and drawn as vector outlines:
const textPath = font.getPath(char, 0, 0, fontSize)
const svgPath = textPath.toPathData(2)
page.drawSvgPath(svgPath, {
x,
y,
color: fillColor,
})
Text-to-path is useful for print and template workflows where the exported PDF must look identical on every machine, even if the recipient does not have the original fonts installed.
The downside is that the resulting text is no longer real text in the PDF. It cannot be selected or searched. File size also increases because every glyph outline becomes drawing data.
For stroked text, we draw the outline first and then draw the fill on top:
page.drawSvgPath(svgPath, {
borderColor: strokeColor,
borderWidth: strokeWidth * 2,
})
page.drawSvgPath(svgPath, {
color: fillColor,
})
Fake bold can be approximated by adding a small stroke around the glyph outline:
const boldStrokeWidth = fontSize * 0.05
page.drawSvgPath(svgPath, {
color: fillColor,
borderColor: fillColor,
borderWidth: boldStrokeWidth,
})
Italic text is handled through matrix transforms:
const italicSkew = -Math.tan(15 * Math.PI / 180)
page.pushOperators(
setTextMatrix(1, 0, italicSkew, 1, x, y),
showText(text),
)
Font Subsetting
When fonts are embedded directly, the PDF does not need the full font file. It only needs the glyphs used in the document.
Our pdf-lib fork supports subsetting through embedFont:
const pdfFont = await pdfDoc.embedFont(fontBuffer, {
subset: true,
customName: fontFamily,
})
During text encoding, each used glyph is recorded:
encodeText(text: string) {
const glyphs = this.font.layout(text, fontFeatures)
for (const glyph of glyphs) {
this.subset.includeGlyph(glyph)
const glyphId = this.glyphIdMap.get(glyph.id)
}
return PDFHexString.of(hexGlyphIds)
}
When the PDF is serialized, only the used glyphs are written:
serializeFont() {
return this.subset.encode()
}
This keeps vector PDFs much smaller, especially for CJK fonts.
For SVG export, font subsetting is handled on the server side with Python fonttools, then injected back into the SVG as WOFF @font-face rules.
Object Rendering Strategy
PdfGenerator dispatches each Fabric.js object to a dedicated handler:
| Fabric.js object |
Handler |
PDF output |
image, barcode, qrcode
|
handleImage() |
Embedded JPEG/PNG image XObject |
textbox |
handleTextbox() |
drawText or drawSvgPath
|
arctext |
handleArctext() |
Per-character positioning and rotation |
waisttext, flagtext
|
handleWarpedText() |
Rasterized PNG fallback |
rect |
handleRect() |
Rectangle path, including rounded corners |
circle |
handleCircle() |
Ellipse path |
triangle |
handleTriangle() |
Triangle path |
polygon, polyline, line, arrow
|
handleLine() |
Move/line operators, plus arrowhead paths |
path |
handlePath() |
SVG path rendered directly |
group, puzzle, table
|
handleGroup() |
Nested transforms plus recursive rendering |
mask |
handleMask() |
Offscreen canvas composition embedded as PNG |
svg |
handleSvg() |
Recursive SVG node parsing |
Groups are especially sensitive because every child inherits the group’s translation, rotation, and scale:
handleGroup(group, page, pageHeight) {
this.pushGraphicsState(page)
this.transformOperator(page, 1, 0, 0, 1, left + width / 2, top + height / 2)
this.transformOperator(page, cos, sin, -sin, cos, 0, 0)
this.transformOperator(page, scaleX, 0, 0, scaleY, 0, 0)
this.transformOperator(page, 1, 0, 0, 1, -width / 2, -height / 2)
for (const child of group.objects) {
this.handleObjects(child, page, pageHeight)
}
this.popGraphicsState(page)
}
Getting this right is what makes nested layouts export correctly.
Gradients
Fabric.js gradients are converted into native PDF shadings.
Linear gradients use PDF Shading Type 2:
const shading = pdfDoc.context.obj({
Type: 'Shading',
ShadingType: 2,
ColorSpace: colorSpace === 2 ? 'DeviceCMYK' : 'DeviceRGB',
Coords: [x1, y1, x2, y2],
Function: buildStitchedColorFunction(stops),
Extend: [true, true],
})
Radial gradients use PDF Shading Type 3:
const shading = pdfDoc.context.obj({
Type: 'Shading',
ShadingType: 3,
Coords: [cx1, cy1, r1, cx2, cy2, r2],
Function: buildStitchedColorFunction(stops),
})
For multiple color stops, the exporter builds a Type 3 stitched function. Each segment is a Type 2 interpolation function:
buildStitchedColorFunction(stops) {
if (stops.length === 1) {
return { FunctionType: 2, Domain: [0, 1], C0: color, C1: color }
}
if (stops.length === 2) {
return { FunctionType: 2, Domain: [0, 1], C0: color1, C1: color2 }
}
return {
FunctionType: 3,
Domain: [0, 1],
Functions: stops.map(pair => type2Function(pair)),
Bounds: internalStopPositions,
Encode: stops.map(() => [0, 1]),
}
}
Gradient resources are collected during rendering and then injected into each page’s resource dictionary in one batch.
CMYK Output
For print-oriented exports, colorSpace = 2 switches colors to CMYK:
private convertColor(color: string): { r, g, b } | { c, m, y, k } {
if (this.colorSpace === 2) {
const k = 1 - Math.max(r, g, b)
return {
c: (1 - r - k) / (1 - k),
m: (1 - g - k) / (1 - k),
y: (1 - b - k) / (1 - k),
k,
}
}
return { r, g, b }
}
In CMYK mode, fills, strokes, and gradient functions all use four-component color values, and the PDF shading dictionaries use DeviceCMYK.
Moving Export Work into a Web Worker
Generating a vector PDF is CPU-heavy. Doing it on the main thread can freeze the editor, especially for multi-page designs with many text objects and SVG paths.
The export flow uses a one-off Web Worker:
Main thread Worker
----------- ------
handleExportPdfByWorker()
|
+-- new Worker(pdf.worker.ts)
|
+-- postMessage({
| type: 'CREATE_PDF',
| requestId,
| templateData,
| colorSpace,
| })
onmessage
|
+-- loadGenerator()
| dynamic import
|
+-- new PdfGenerator()
+-- generator.createPdf()
| preload fonts
| preload images
| render objects
|
PDF_PROGRESS <------------------------+
PDF_DONE <------------------------+
PDF_ERROR <------------------------+
Important details:
- A fresh Worker is created for each export and terminated when the job finishes.
-
PdfGenerator is lazy-loaded inside the Worker to avoid increasing initial app startup cost.
- Each request has a
requestId, so concurrent or stale responses can be ignored safely.
- If Worker export fails, the system falls back to main-thread export.
try {
const result = await handleExportPdfByWorker(templateData, colorSpace)
return result
} catch (error) {
console.warn('Worker export failed, falling back to main thread')
return await handleExportPdfMainThread(templateData, colorSpace)
}
The Worker environment also needs a few shims because some Fabric.js code expects DOM-like APIs:
class WorkerStyleDeclaration {
// Minimal CSSStyleDeclaration replacement.
}
import { parseXmlString } from 'txml'
setEnv({ isNode: true })
Export Context Isolation
The exporter loads Fabric.js JSON through a separate FabricStatic canvas and sets an internal export flag while deserializing:
let _isExportContext = false
export class FabricStatic extends StaticCanvas {
loadFromJSON(json, reviver) {
_isExportContext = true
return super.loadFromJSON(json, reviver).finally(() => {
_isExportContext = false
})
}
}
Other parts of the editor check this flag to adjust behavior during export:
- Skip UI-only rendering logic.
- Disable object caching for maximum output quality.
- Hide guides and helper elements.
- Skip animations.
This keeps the export pipeline isolated from interactive editor behavior.
Performance Optimizations
Before rendering, the exporter recursively collects all image URLs and font families, then preloads them in parallel:
const allImages = collectImageUrls(template)
const allFonts = collectFontFamilies(template)
await Promise.all([
...allImages.map(url => preloadImage(url)),
...allFonts.map(family => preloadFont(family)),
])
Images and fonts are cached so the same resource is only embedded once:
private imageCache = new Map<string, PDFImage>()
private pdfFontCache = new Map<string, PDFFont>()
For multi-page documents, pages can be rendered in parallel while keeping CTM state isolated per page:
const pagePromises = templates.map((template, index) => {
return Promise.resolve().then(() => {
this.ctmPerPage.set(page, initialCTM)
this.ctmStackPerPage.set(page, [])
this.handleObjects(template.objects, page, pageHeight)
})
})
await Promise.all(pagePromises)
The exporter also records timing information for each phase:
type PdfExportTimings = {
preloadMs: number
drawMs: number
saveMs: number
totalMs: number
bytes: number
}
That makes it easier to tell whether a slow export is caused by resource loading, object rendering, or final PDF serialization.
Results
For a typical design containing text, shapes, images, and gradients, the difference looks roughly like this:
| Metric |
Raster PDF |
Vector PDF |
| File size |
around 2.5 MB |
around 800 KB |
| Selectable text |
No |
Yes, unless text-to-path is enabled |
| Infinite zoom without blur |
No |
Yes |
| Export time |
around 1 second |
around 3-5 seconds |
| CMYK print workflow |
No |
Yes |
When text-to-path is enabled, file size usually increases by about 30-50%, but the exported PDF becomes independent of installed fonts.
Takeaways
Building real vector PDF export in the browser is possible, but the difficult parts are not the PDF file creation itself. The hard parts are all the details around visual fidelity:
- Matching Fabric.js coordinates to PDF coordinates.
- Tracking CTM state through nested transforms.
- Converting SVG paths, especially elliptical arcs.
- Handling text as either fonts or glyph outlines.
- Supporting gradients and CMYK color spaces.
- Keeping export work off the main thread.
- Avoiding duplicated resources in multi-page documents.
For YFT Design Pro, this approach gives us browser-only PDF export that is much closer to what users expect from a desktop design tool: smaller files, crisp vector output, optional font-safe text outlines, and print-oriented CMYK support.
YFT Design Pro is an open-source online design editor built with Fabric.js and Vue 3. It supports multi-page editing, vector PDF export, SVG export, and print-focused workflows.
Tamamen elektrikli SUV modeli Xiaomi YU7 GT, elde edilen 7:34.931’lik Nordschleife turuyla rekor kırdı. Çinli “Ren Zhoucan” tarafından kontrol edilen araç, Audi RS Q8 Performance’ın 7:36.698’lik derecesini geçerek efsane pistin en hızlı seri üretim SUV’si oldu. Resmi olarak 21 Mayıs’ta satışa sunulacak YU7 GT, taşıdığı 386 ve 604 beygirlik iki farklı elektrik motoruyla toplam 990 beygir güç ortaya koyuyor. Yeni bir havalı süspansiyon ve arka aks tork yönlendirme sisteminin kullanıldığı araç, çekiş kontrol sisteminde daha sportif sürüş ve yüksek güce özel ayarlamalar taşıyor. 300 km/s hıza çıkabilen aracın 0’dan 100 km/s hıza 2 saniye civarında ulaşabileceği söylenirken, opsiyonel olarak Brembo imzalı karbon seramik fren sistemiyle donatılabilecek YU7 GT’nin ilk aşamada yalnızca Çin’de satılacağı belirtiliyor.
LG tarafından yapılan açıklamaya göre birçok benzerinden farklı olarak 720p değil 1080p’de (1920×1080) “1.000 Hz” yenileme hızı sunabilen oyuncu monitörü UltraGear 25G590B, yılın ikinci yarısında satışa sunulacak. Doğrudan profesyonel oyunculara odaklanan modelde, 24,5 inç boyutunda IPS panele yer verilecek. Otomatik görüntü ayarlamaları sunan sistem gibi çeşitli yapay zeka destekli özellikler taşıyacak monitörün satış fiyatı henüz paylaşılmıyor.
Önümüzdeki ayın başında tanıtılacak iOS 27 işletim sistemiyle sunulacak üç yeni yapay zeka yeniliği paylaşıldı. Bloomberg’den Mark Gurman’a göre bu yeniliklerden ilki, gücünü Image Playground için kullanılan teknolojilerden alacak bir duvar kağıdı oluşturma sistemi olacak. Kullanıcılar bu altyapı sayesinde yapay zekaya söyleyerek telefonları için farklı duvar kağıtları üretebilecek. Buna ek olarak yeni yapay zeka tabanlı yazma araçlarının geleceği ve bunlar arasında Grammarly’ye benzer şekilde çalışan bir yazım denetleyicisinin olacağı da aktarılıyor. Apple’ın aynı zamanda, kullanıcıların Shortcuts (Kestirmeler) uygulamasında yazılı komutlarla işlem yapabilmesini sağlayacağı söyleniyor. Gurman’a göre kullanıcılar yazılı komutlarla yeni kestirmeler oluşturabilecek.