PDFlibPas vẽ văn bản tiếng Nhật và tiếng Trung chạy dọc xuống trang. SetVerticalWritingMode bật chế độ viết dọc, khi đó các lệnh DrawText thông thường chạy xuống dưới, còn GetVerticalWritingMode báo cáo trạng thái hiện tại. Trước khi tính năng này tồn tại, đặt văn bản theo chiều dọc nghĩa là phải định vị từng ký tự bằng tay và hy vọng khoảng cách trông ổn
Văn dọc không phải là văn ngang xoay chín mươi độ. Các ký tự vẫn đứng thẳng, bước tiến chạy xuống thay vì ngang, và một số ký tự thay đổi hình dạng hoàn toàn — đó là phần phân biệt một tài liệu đọc tự nhiên với một tài liệu mà người đọc Nhật Bản nhận ra ngay là máy làm ra
Những gì thay đổi bên trong PDF
Văn bản được vẽ theo cách này đi qua một font Type0 trong chế độ viết dọc, mang theo metric dọc của chính typeface. Điều đó quan trọng theo hai hướng. Một trình đọc tiến từng ký tự đúng khoảng cách mà nhà thiết kế typeface dự định thay vì một bước đều đặn, nên cột giữ được nhịp điệu mà typeface được vẽ ra cho. Và sao chép văn bản ra trả về các ký tự gốc, vì dòng dọc vẫn là văn bản thực với một ánh xạ đúng đắn chứ không phải là một chuỗi glyph đã định vị
Một typeface không mang metric dọc riêng của nó sẽ tiến một em mỗi ký tự, đó là điều mà một trình đọc sẽ làm theo mặc định. Fallback đó đáng biết đến vì nó chính là sự khác biệt bạn sẽ thấy khi một tài liệu render đúng với một typeface CJK chuẩn và trông có khoảng cách cơ khí với một typeface Latin tình cờ có chứa vài kana
var
Lib: TPDFlib;
H: Double;
begin
Lib := TPDFlib.Create;
try
Lib.SetOrigin(1);
Lib.AddTrueTypeFont('MS Mincho', 1); // 1 = embed the face
Lib.SetTextSize(12);
Lib.SetVerticalWritingMode(1); // ordinary DrawText now runs down
H := Lib.GetVerticalTextHeight('MS Mincho', 12, '第三章 保守点検');
Lib.DrawText(480, 72, '第三章 保守点検');
Lib.SetVerticalWritingMode(0); // back to horizontal
Lib.DrawText(72, 72 + H, 'Chapter 3');
Lib.SaveToFile('manual-ja.pdf');
finally
Lib.Free;
end;
end;
Vì sao dấu ngoặc trông sai trong văn bản dọc?
Vì một dấu ngoặc có hai dạng và chỉ một trong số đó thuộc về một cột. Dấu ngoặc, dấu nguyên âm dài và kana nhỏ được vẽ khác khi văn bản chạy dọc xuống trang — một dấu ngoặc đơn xoay để nằm dọc theo cột thay vì nằm ngang qua nó, còn dấu nguyên âm dài trở thành một nét đứng. Vẽ dạng ngang trong một cột dọc thì mỗi ký tự sẽ nằm nghiêng một bên
PDFlibPas lấy các dạng từ chính tính năng dọc của font, nên mỗi typeface cung cấp những gì nhà thiết kế của nó đã vẽ thay vì một phép thay thế được đoán từ ký tự. Sự phân biệt đó quan trọng cho tính đúng đắn: một bảng thay thế đoán thì đúng với các trường hợp phổ biến và sai với những typeface đối xử với một ký tự khác đi, còn một typeface không khai báo dạng dọc nào được vẽ y như trước thay vì bị ép qua một bảng mà nó không hề yêu cầu
GetVerticalTextHeight đo các dạng thực sự sẽ được vẽ ra, nên một cột mà các ký tự thay đổi hình dạng vẫn được đo đúng. Đo các dạng ngang rồi vẽ các dạng dọc là nguồn kinh điển của những cột bị tràn khung một vài ký tự
Vẽ một dòng mà không đổi chế độ
DrawVerticalText vẽ một dòng đơn theo chiều dọc, nhận vị trí, tên font, kích cỡ và văn bản, để nguyên chế độ viết. Hãy dùng nó cho trường hợp ngoại lệ dọc bên trong một tài liệu ngang — một nhãn sống lưng, một con dấu, một cột tên duy nhất — nơi việc bật tắt một chế độ toàn cục quanh mỗi lệnh gọi lại là nhiều trạng thái hơn mức nhiệm vụ cần
Dạng ngang và dạng dọc của cùng một typeface được tách rời nội bộ, nên một trang có thể mang cả hai mà không bên nào làm phiền bên kia. Đó là điều khiến một trang hỗn hợp trở nên khả thi: một trang sách Nhật với thân bài dọc và đầu trang chạy ngang, hay một chứng chỉ Trung Quốc với nhan đề dọc nằm trên các dòng chi tiết ngang
// One vertical run inside an otherwise horizontal page
Lib.DrawVerticalText(520, 96, 'MS Mincho', 14, '保守点検記録');
// The horizontal text around it is unaffected
Lib.DrawText(72, 96, 'Maintenance inspection record');
Đưa font về đúng trước bất cứ thứ gì khác
Văn dọc phụ thuộc hoàn toàn vào typeface. Một font CJK với metric dọc chuẩn và một tính năng dọc tạo ra đầu ra đúng mà không cần làm gì thêm; một font thiếu chúng tạo ra ký tự đứng thẳng tiến một em mỗi ký tự và hoàn toàn không có thay đổi hình dạng. Nếu văn bản dọc trông sai tinh tế, hãy kiểm tra font trước khi kiểm tra mã
Việc nhúng tuân theo các quy tắc thường thấy và chi phí thường thấy. Một typeface CJK đầy đủ có kích thước lớn, nên subsetting không phải là tùy chọn đối với các tài liệu đi bất cứ đâu — các ghi chú về tối ưu kích thước file PDF và font subsetting trình bày điều cần trông đợi, còn bài viết về nhúng font thiếu vào một PDF hiện có trình bày trường hợp sửa chữa khi một tài liệu dọc đến tay mà không có font của nó
Nơi văn bản dọc vẫn cần một quyết định bố cục từ bạn
Thứ tự cột. Văn dọc Nhật chạy từ phải sang trái theo cột, nên một trang hai cột bắt đầu từ mép phải, và không thiết lập chế độ viết nào có thể suy ra điều đó từ văn bản. Điều tương tự áp dụng cho thứ tự trang trong một tài liệu đọc từ phải sang trái nhìn tổng thể, và cho vị trí của furigana, chú thích cuối trang và chú thích hình
Điều mà thư viện đảm bảo là mỗi dòng được đặt đúng: dạng đúng, bước tiến đúng, văn bản có thể trích xuất. Việc các dòng đi đâu trên trang là một vấn đề bố cục, và đối với các tài liệu lắp ráp từ dữ liệu, bài viết về tìm kiếm văn bản và liệt kê phần tử trang hữu ích để xác thực sau đó rằng thứ đáp xuống trang chính là thứ bạn dự định
PDFlibPas là thư viện PDF Pascal bản địa cho Delphi, C++Builder và Lazarus, và văn dọc CJK là một phần của API vẽ thay vì một bổ sung rời rạc — xem trang sản phẩm PDFlibPas để biết danh sách tính năng văn bản và font