Tôi rất quan tâm đến giao điểm giữa ebook, bảo mật và web LowJS, nên chủ đề này có ý nghĩa quan trọng với tôi
Cần có một định dạng ebook di động dưới dạng một tệp duy nhất, nhưng PDF không phải câu trả lời vì không thể tái lưu chuyển văn bản
HTML+CSS của năm 2024 có thể tái hiện gần như mọi ấn phẩm in mà vẫn cho phép tái lưu chuyển văn bản
Tôi không nghĩ JavaScript nên là bắt buộc. Ebook phải là một cuốn sách có thể thay đổi kích thước một cách có ý nghĩa, và ngay cả khi tắt JavaScript, các chức năng cơ bản với tư cách là sách vẫn phải hoạt động. Nếu cần tương tác hoặc bổ sung thì có thể dùng JavaScript, nhưng nếu không có JavaScript mà nó không hoạt động như một cuốn sách thì tôi xem đó là lỗi
Tôi nghĩ đưa toàn bộ style vào inline là một sai lầm vì có thể phá vỡ CSP của một số người dùng. Nên tách style thành tài nguyên dùng đường dẫn tương đối theo HTML, và ebook phải cấm tải tài nguyên từ các domain khác
Cuối cùng, chỉ cần phân phối dưới dạng tệp zip là được. Tôi nghĩ ebook vốn đã hoạt động kiểu như vậy rồi không phải sao
“Ebook vốn đã hoạt động như zip hay chưa” thì ở mức nào đó là đúng. Các công cụ unzip có thể giải nén tệp EPUB, và nếu cần chỉ cần đổi phần mở rộng từ .epub sang .zip
Nhưng chiều ngược lại thì không nhất thiết đúng. Ngay cả khi cùng một bộ tệp là EPUB hợp lệ trước khi giải nén, nếu nén lại thành zip tùy tiện thì có thể không còn là EPUB hợp lệ Tệp mimetype bên trong zip EPUB là đặc biệt: nó phải là mục đầu tiên trong archive, nội dung chỉ được là application/epub+zip, và phải được lưu ở trạng thái không nén
Bất ngờ là nhiều công cụ zip khiến việc này phiền phức vì chúng đổi thứ tự tệp hoặc làm cho việc chỉ lưu một số tệp ở dạng không nén trở nên khó. Chương trình zip dòng lệnh thường làm được bằng cờ, nhưng trong thư viện zip thì khá đau đầu. Đây là kinh nghiệm từ việc từng làm phần mềm tạo EPUB
Điều quan trọng là phải phân biệt tệp zip thông thường với ebook. Chỉ cần dùng phần mở rộng .epub là được
Thứ được mô tả chính là định dạng ePub, trong đó các tệp HTML, CSS và hình ảnh nằm trong một archive zip
Tôi không thích lắm cách gói mọi thứ vào zip
Điểm mà các tệp .doc cũ dùng thích hơn .docx là trong một thư mục có hàng trăm đến hàng nghìn tệp, có thể tìm kiếm một từ cụ thể rất nhanh. Với định dạng zip thì không làm được điều đó
Tôi vừa lưu thành .doc rồi mở bằng trình chỉnh sửa hex, và thấy nội dung thực sự nằm ở dạng văn bản thuần. Định dạng zip hay tệp PDF khó tìm bằng grep, và tôi cũng nghi ngờ liệu vài nghìn ký tự văn bản có thật sự cần nén hay không
Đây là một bài viết rất bài bản của nhà phát triển Nota, nhằm đưa định dạng EPUB lên ngang tầm PDF. Họ đã làm cả trình xem, và bản thân bài viết cũng đang được hiển thị bằng bản port WASM chạy trên trình duyệt của trình xem đó
Một trong các vấn đề là EPUB, về thực chất là XHTML, có thể tái hiện bố cục chính xác đến mức nào. Tiêu chí trong bài gốc là tài liệu trông “hợp lý”, nhưng để sánh với PDF thì có vẻ ít nhất HTML cần các tính năng bố cục mới ở phần ngắt dòng
Tôi thấy có hai hướng tiến lên. Một là trình duyệt cung cấp nhiều công cụ typography hơn; text-wrap: pretty được nói là có ích, nhưng khi tôi thử nhanh thì không thấy chất lượng ngắt dòng tốt hơn. Hướng còn lại là tính trước việc ngắt dòng, nhưng điều này chỉ khả thi với rendering bố cục cố định
Ngoài ra, tác giả có nhắc đến chú thích, nhưng tôi không rõ họ định triển khai như thế nào
Tác giả cũng bàn về EPUB bố cục cố định. EPUB có thể chỉ định phân trang mặc định, ngắt dòng, phông chữ, cỡ chữ, kích thước trang, vị trí hình ảnh, v.v. để được render giống nhau ở mọi nơi
Điều này đã khả thi trong EPUB3, nhưng nhược điểm là trên các màn hình như điện thoại thì trông không đẹp. Tùy trình đọc, có thể ghi đè các giá trị mặc định, nhưng khi đó phải kỳ vọng trình đọc tái tạo lại tài liệu sao cho đẹp
Một phương án thay thế là EPUB chỉ định nhiều bản render cho các kiểu màn hình phổ biến. Dù không hoàn hảo, việc để người tạo tài liệu cung cấp mặc định và cho phép người dùng ghi đè nếu muốn có vẻ là một thỏa hiệp tốt
PDF không có chức năng ngắt dòng. Nó gần với một định dạng hình vẽ giống SVG hơn, và cứng nhắc hơn nên không có những thứ như tái lưu chuyển văn bản
Thứ một định dạng ebook cần là markup ngữ nghĩa thích ứng với thiết bị render. HTML+CSS vốn được tạo ra cho mục đích đó
Vì vậy, người thiết kế bố cục sách phải có ý thức trao một phần quyền kiểm soát việc cuốn sách trông thế nào cho độc giả. Một chút không hoàn hảo về thị giác là cái giá đáng trả. Nếu cần sự hoàn hảo về thị giác thì dùng PDF
Tất nhiên, khi có yếu tố tương tác thì sẽ khó hơn. Có lẽ tốt nhất là các yếu tố tương tác lớn mở trong một chế độ xem chuyên dụng khi cần, còn các yếu tố tương tác nhỏ thì chấp nhận tái lưu chuyển
Tôi nghĩ CSS về cơ bản có hỗ trợ tính năng bố cục cho phương tiện phân trang. Có phải trình đọc EPUB chỉ cần triển khai chế độ hiển thị “xem trước khi in” truyền thống là được không
Trớ trêu là chính ví dụ chú thích mà tác giả đưa ra lại không hoạt động đúng trong môi trường của tôi. Trên Android Firefox màn hình cảm ứng, nhấn giữ thì hiện liên kết thay vì popup
Tôi nghĩ chú thích và tham chiếu vốn đã có trong đặc tả EPUB, có khi cả đặc tả HTML nữa
Tôi cũng không đồng ý rằng cách nhấn giữ để hiện popup tốt hơn anchor hyperlink thông thường. Nếu chức năng “quay lại” của trình đọc hoạt động đúng, hoặc tham chiếu hai chiều có liên kết “quay lại”, thì cách điều hướng sẽ ít gây gián đoạn hơn nhiều
Ngày xưa từng có một thứ gọi là XSL Formatting Objects(XSL-FO). Nó hướng tới một thứ giống PDF dựa trên XML, nhưng ở cấp cao hơn nên cũng có thể tái lưu chuyển văn bản
Ý tưởng là phân phối tài liệu XML cùng với stylesheet XSL, chuyển đổi thành FO để render, và có thể có nhiều stylesheet cho cùng một tài liệu tùy theo thiết bị đích hoặc kích thước trang
Trong Firefox, tôi dùng tiện ích SinglePage để lưu DOM của trang hiện tại thành một tệp HTML độc lập. Cách làm là nhúng inline CSS và URL data: cho hình ảnh, rồi loại bỏ các phụ thuộc và script
Không hoàn hảo, và tôi cũng không tin rằng trình duyệt sẽ luôn duy trì tương thích ngược, nhưng tôi thích cách này hơn việc lưu trang thành PDF hoặc thành nhiều tệp
Thú vị là một trong số ít trang mà tiện ích này thất bại lại chính là bài viết này về EPUB di động. Có vẻ như đã có quá nhiều “ma thuật” để căn chỉnh định dạng. Trang đã lưu vẫn đọc được, nhưng style thì hoàn toàn khác bản gốc
Tôi thích việc fbreader trên Android hiển thị mọi cuốn sách giống nhau theo thiết lập của ứng dụng, thay vì theo style của tệp EPUB. Tôi chưa từng thấy nó áp dụng CSS hay cố chạy script có trong tệp, và hy vọng sau này cũng không như vậy. Tải các phụ thuộc bên ngoài còn là ý tưởng tệ hơn, và ngay từ đầu tôi cũng không biết là việc đó được cho phép
Có lẽ bạn đang nói đến SingleFile
Nhân tiện chuyện đó, hệ thống quyền của tiện ích Firefox khá kỳ lạ. Để làm được việc gì thú vị thì gần như phải yêu cầu mọi quyền, và kết quả là hình thành một thị trường tự nhiên cho những kẻ độc hại đi săn mua các tiện ích để tiếp quản
Ví dụ, tiện ích SingleFile đúng là cần quyền truy cập vì nó phải nhìn vào DOM đã render rồi lưu thành tệp. Nhưng tại sao nó lại phải truy cập mọi thứ? Không thể chỉ cấp các quyền kiểu snapshot DOM once, write to a single file thôi sao
Tôi nhớ một trong những bình luận đầu tiên tôi viết trên HN khoảng 10 năm trước là về việc muốn lưu trang web HTML dưới dạng HTML, chứ không phải PDF
Khi đó có lẽ tôi cũng không giải thích được lý do cho rõ, thậm chí cũng chưa hiểu hết, nhưng mong muốn ấy bị xem như điều vô lý. Giờ nhìn lại, có vẻ tôi chỉ lệch thời khoảng 10 năm, nên thấy khá vui
Lý do trang này khó parse đã được một bình luận khác giải thích rất rõ. Đây là bài viết của nhà phát triển Nota về việc đưa EPUB lên ngang tầm PDF, và bản thân bài viết đang được hiển thị bằng một trình xem dựa trên WASM trong trình duyệt
FBReader mặc định dùng CSS của tài liệu. Nếu tôi nhớ không nhầm thì có thể tắt trong khoảng bốn bước
KOReader kém thân thiện hơn nhưng cho nhiều quyền kiểm soát hơn. Bạn có thể chọn một tệp cụ thể trong số nhiều tệp CSS được cung cấp, hoặc tự viết CSS của mình
Điểm mạnh của KOReader còn có hỗ trợ OPDS xuất sắc và máy chủ đồng bộ tự host dễ thiết lập
Bài này có nút tải EPUB
Khi có tính năng này, các trang dùng hệ thống này sẽ không cần SinglePage nữa
Nhìn phần đó rồi tôi đã xem lại. Đó là đoạn: “Vì vậy, chúng tôi quyết định tạo Bene, một hệ thống đọc EPUB nhẹ hơn. Đây chính là thứ các bạn đang dùng. Tài liệu này là một EPUB, và có thể tải xuống bằng cách nhấn nút ở góc trên bên phải”
Khi đọc trên trình duyệt desktop, tôi hoàn toàn không nhận ra cho đến khi được chỉ trực tiếp. Trên di động thì phần header chiếm nhiều màn hình hơn nên dễ thấy hơn, nhưng ngoài chuyện đó ra nó hoạt động gần như một trang web bình thường
Có lẽ đó là một tín hiệu tốt
Trái với một số bình luận đã nói, khi tải tài liệu lần đầu tôi không thấy, hoặc ít nhất là không để ý thấy, spinner. Trên điện thoại thì có thấy, nhưng nó trôi qua khá nhanh. Tôi không biết đó có phải là lúc tải chương trình WASM hay chỉ xảy ra ở lần tải đầu tiên không
Thứ spinner chủ yếu chờ là tải tệp .epub. Tệp đó nặng 4,77MB nên nếu không có kết nối nhanh thì khá lớn. Sau khi giải nén, phần lớn dung lượng là hình ảnh, khoảng 99%
Khác với trang web thông thường hay PDF, có vẻ như việc render không bắt đầu cho đến khi toàn bộ tài nguyên, tức toàn bộ ePub, được tải xuống
Một khác biệt mà tôi tưởng bài viết sẽ đề cập nhưng lại không nói đến là hiệu năng. PDF có thể được tối ưu để các trang khá độc lập với nhau, cho phép render tăng dần, truy cập ngẫu nhiên và song song hóa cao
Trên điện thoại, tôi hoàn toàn không nhận ra cho đến khi đọc bài. Tôi chỉ nghĩ đó là một trang web bình thường giải thích về dự án
Chỉ riêng việc trình duyệt không mở được EPUB đã khiến dự án này có cảm giác như phần nào đã được định sẵn là sẽ thất bại. Với PDF, nếu liên kết tới thì dù có chút chuyển ngữ cảnh, trình duyệt vẫn mở và hiển thị được
EPUB, theo mô tả, về cơ bản là HTML, nên việc trình duyệt không mở được là lạ, nhưng có vẻ sẽ không dễ thuyết phục các quan chức ở Chrome/Mozilla
Một điểm đáng nản nữa là HTML và CSS đã trở nên quá khổng lồ và cồng kềnh, đến mức gần như không còn mấy ai có thể triển khai một “trình đọc” cho EPUB/HTML. Về cơ bản nó trở thành “hãy triển khai một trình duyệt mới”. Về dài hạn, cách dùng một Markdown dễ phân tích cú pháp như Djot rồi thêm chút khả năng render có vẻ khả thi hơn
Phương án thỏa hiệp tạm thời của cá nhân tôi là đưa toàn bộ CSS, SVG, script, thậm chí ảnh base64 vào một file HTML duy nhất. Nó tương tự EPUB, hơi cồng kềnh và xấu xí, nhưng chỉ cần để ý một chút là chạy được và trình duyệt có thể mở một cách tự nhiên
Tuy nhiên người dùng không có cách nào biết rằng “mình có thể tải trang web này xuống và lưu ngoại tuyến”. Sẽ hay nếu có một phần mở rộng như .htmls để biểu thị đây là HTML không có tài nguyên bên ngoài
Cho đến cách đây không lâu, trình duyệt cũng không mở được PDF. Giờ thì mọi trình duyệt đều bao gồm trình đọc PDF viết bằng ASM/JS
Có vẻ không có lý do gì trình duyệt không thể làm điều tương tự với EPUB. Đã có tiện ích mở rộng trình duyệt làm đúng việc đó rồi. Vấn đề là định dạng EPUB có đạt được độ phổ biến hay không
HTML ban đầu là siêu văn bản. Chỉ có vài liên kết, hình/ảnh, bảng biểu ở mức độ nào đó
Rồi thiết kế và bố cục kiểu tạp chí trở nên “cần thiết”, nhưng vì vẫn dựa trên tài liệu nên cũng khá ổn
Sau đó người ta cố nhồi HTML vào vai trò nền tảng phân phối ứng dụng. Bố cục CSS hiện nay cuối cùng đã gần hơn với các engine bố cục ứng dụng truyền thống
Tôi cho rằng 20 năm qua phần lớn đã bị lãng phí vì không có một cách phân phối ứng dụng đa nền tảng phù hợp. Ngoại trừ Java
Vậy nên bản thân bài viết này có vẻ là một EPUB được mở bằng trình xem EPUB WASM
Rào cản lớn nhất có vẻ là phạm vi triển khai HTML/CSS. Tác giả nói “Nguyên tắc tạo HTML di động: nếu có thể, hệ thống tạo EPUB di động nên xuất HTML di động”, nhưng dường như như vậy vẫn chưa đi đủ xa
Để định dạng này hoạt động có thể lặp lại ở mọi nơi, nó phải được chuẩn hóa và cũng phải dễ triển khai engine render mới. Cách phụ thuộc vào webview không có vẻ là con đường tiến lên
Vẻ đẹp của PDF nằm ở chỗ nó rất đáng tin cậy. Một file PDF từ 10 năm trước hôm nay vẫn được render y như trước
Để nỗ lực kiểu này thành công, có lẽ cần thu hẹp phạm vi tài liệu rất nhiều. Tập con XHTML được phép phải rất hạn chế, và phải ưu tiên khả năng render giống nhau ở mọi nơi. Trước hết nên là bố cục cố định với kích thước trang cố định, sau đó mới đến tài liệu có thể reflow. Cũng cần một tiêu chuẩn có các tài liệu kiểm thử toàn diện và đầu ra render đi kèm
Trình duyệt không cung cấp UI tiện lợi để mở EPUB, nhưng về việc render các file HTML theo từng chương bên trong thì lẽ ra không có vấn đề
Nếu không có hỗ trợ từ trình duyệt, việc viết một proxy phía máy chủ để biến EPUB thành một site có thể duyệt, kèm điều khiển chuyển chương và một vài tùy chọn bố cục đơn giản, có lẽ không quá khó
Dĩ nhiên để xem phần lớn ebook thương mại bằng proxy như vậy, hỗ trợ DRM cần thiết rất có khả năng sẽ là vấn đề pháp lý nghiêm trọng
Nghĩ lại thì hỗ trợ EPUB DRM được nhà xuất bản chấp thuận trong trình duyệt về mặt kỹ thuật chỉ cách hỗ trợ DRM cho trang web thông thường nửa bước, và đó là một viễn cảnh khá kinh khủng
Tôi nghĩ PDF là một định dạng legacy tệ hại với độ phức tạp không cần thiết. Phần lớn cách dùng PDF không liên quan gì đến in ấn, nên logic dàn trang cũng không thuyết phục
Trong đa số trường hợp sử dụng, việc dễ đọc trên điện thoại, máy tính bảng và máy tính quan trọng hơn nhiều
Tác giả nói iBooks không hỗ trợ chế độ cuộn khiến tôi ngạc nhiên nên đã tự kiểm tra. iBooks trên macOS không hỗ trợ cuộn file ePub, nhưng trên iOS và iPadOS thì có. Một quyết định rất kỳ lạ của Apple https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Đặc tả PDF thì phiền phức, nhưng hoàn toàn không có thứ gì thay thế được nó
Tôi chưa từng thấy tài liệu kỹ thuật được phân phối ở định dạng không phải PDF mà lại tiện cho đọc và tìm kiếm. Trên điện thoại cũng vậy
Tôi không muốn tài liệu có hình thức thay đổi tùy theo trạng thái nhất thời như thiết bị đọc hay kích thước cửa sổ. Tôi muốn tài liệu có bố cục cố định do tác giả thiết kế tốt
Ngay cả khi đọc trên màn hình hoặc cửa sổ nhỏ, nếu đó không phải tài liệu văn bản thuần túy, tôi muốn một trình đọc thông minh giúp phóng to/thu nhỏ và di chuyển nhanh, chứ không phải thay đổi bố cục. Nó không nên có hành vi ngớ ngẩn như một số trình đọc Android, nơi cuộn dọc hoặc Page Up/Page Down lại làm dịch cả vị trí ngang, khiến việc đọc các cột văn bản trở nên khó khăn
Chỉ cần tuân thủ khuyến nghị truyền thống về độ rộng tối đa của cột văn bản là đã đủ để đọc thoải mái trên điện thoại. Việc đọc trên điện thoại chỉ trở nên khó chịu khi tác giả tạo cột quá rộng và phá vỡ các quy tắc typography truyền thống
Lý do muốn tài liệu bố cục cố định không chỉ là vì in ấn. Đó là vì việc cố định bố cục tài liệu quan trọng hơn màn hình nhỏ
Tôi không rõ trường hợp cụ thể này, nhưng một số trình đọc có thể làm vậy vì tính nhất quán với thiết bị giấy điện tử. Giấy điện tử bị hạn chế phần cứng về cuộn do tần số làm tươi thấp, bộ xử lý yếu và nhu cầu tiết kiệm pin
Vì vậy, cố tạo một tiêu chuẩn duy nhất phù hợp với mọi thứ có vẻ là ý tưởng tệ. Tiêu chuẩn tài liệu số có lẽ nên có hai loại. Một loại là định dạng có đầy đủ khả năng đa phương tiện và tương tác, trừ networking; loại còn lại là một tập con của nó, giới hạn ở đen trắng, không có đa phương tiện, và tương tác chủ yếu chỉ ở mức siêu liên kết trong tài liệu
Và thực ra gần như đã có hai định dạng như vậy rồi. HTML, MHTML=EML, và EPUB
Tất nhiên cũng cần một định dạng thứ ba cho lưu trữ vật lý và các tài liệu số bố cục cố định hiếm gặp, và PDF/A có vẻ đã làm vai trò đó khá tốt
Nếu thật sự cần in thứ gì đó, PDF là con đường đáng tin cậy và di động nhất
SVG nhiều trang có thể cũng khả thi, nhưng để in nhiều trang cho đúng, rốt cuộc có lẽ vẫn phải xuất sang PDF trước. Tôi nói vậy khi nhìn vào Inkscape
Mình tò mò trình đọc EPUB cung cấp gì mà trình duyệt không có. Nhìn hiện tại thì câu trả lời dường như chỉ có đúng một thứ, khá nhỏ: tệp .epub, tức là khả năng xử lý tệp zip như một thư mục
Nếu khác biệt giữa trình đọc EPUB và một tập con của trình duyệt thực sự chỉ có vậy, thì cách đơn giản nhất và ít tốn công nhất có lẽ là thế này
Cho các trình duyệt hiện có xử lý tệp zip như thư mục trong một số điều kiện nhất định
Định nghĩa một giới hạn HTML có thể kiểm tra bằng máy, bảo đảm tài nguyên hoàn toàn cục bộ như bài gốc nói. Chỉ cần yêu cầu mọi URL, ngoại trừ liên kết, phải là đường dẫn tương đối có thể đã đủ
Tuyên bố các tệp zip thỏa giới hạn này là “EPUB di động”
Quên hết các trình đọc EPUB chuyên dụng, dù cũ hay mới
Đồng ý. Nghe như đây mới là giải pháp thật sự
Với tài nguyên hoàn toàn cục bộ, mình muốn thấy yêu cầu rằng mọi đối tượng đều phải có phương án thay thế khả dụng cục bộ. Kiểu như nếu không lấy được phông chữ đó thì dùng phông chuẩn. Có thể trông không hoàn hảo, nhưng nếu giới hạn trong phạm vi fallback thì nó vẫn nên hoạt động hợp lý
Có một chế độ lỗi vẫn chưa được xử lý đủ: hình ảnh không hoạt động đúng. Về cơ bản là vì hình ảnh không thể reflow. Phần lớn có thể giải quyết bằng cách dùng SVG, nhưng với hình raster thật thì không được. Cuối cùng có lẽ chỉ còn cách cung cấp vài độ phân giải khác nhau
Mình cũng gặp một vấn đề liên quan nhưng chưa thấy câu trả lời hay. Đó là SVG nhận biết độ phân giải và tải hình chi tiết hơn khi có đủ độ phân giải. Nếu vẽ các đường subpixel thì chúng bị mờ, nhưng khi phóng to cùng hình ảnh đó thì các đường ấy lại trở nên hữu ích. Biểu tượng Windows thừa nhận điều này bằng cách có thể chứa nhiều độ phân giải và dùng bản phù hợp với ngữ cảnh
Tác giả là nghiên cứu viên sau tiến sĩ dưới sự hướng dẫn của Shriram Krishnamurthi. Shriram Krishnamurthi là tác giả của Programming Languages: Application and Interpretation(PLAI) và là một trong các tác giả của Data-Centric Introduction to Computing(DCIC)
Hiện mình đang đọc cả PLAI lẫn DCIC, và thật sự ấn tượng trước sự chăm chút tỉ mỉ mà các tác giả đã bỏ ra để biến chúng thành những tác phẩm nghệ thuật phục vụ giáo dục. Đó đúng là tình yêu thật sự https://willcrichton.net/
PDF có thể nhúng phông chữ, nhưng thường không nhúng và phụ thuộc vào phông hệ thống. Một lý do là đưa phông chữ vào PDF có thể làm kích thước tệp tăng mạnh. Trong một số trường hợp, một phông chữ đơn lẻ có thể còn lớn hơn toàn bộ phần còn lại của tệp
Mình từng triển khai việc nhúng phông trong phần mềm tạo PDF, và việc tìm ra cách làm cho nó hoạt động ổn định hóa ra khó hơn tưởng tượng
Việc PDF được render nhất quán cũng không đúng như nhiều người nghĩ. Nhiều lần cùng một PDF render khác nhau tùy trình xem PDF được dùng. Thường khác biệt rất tinh vi, nhưng đôi khi cũng có các trường hợp biên khác biệt khá lớn. Mình cũng từng gặp trường hợp cùng một phiên bản Acrobat Reader render PDF khác nhau tùy hệ điều hành
Chỉ có vài phông hệ thống tiêu chuẩn có thể được lược bỏ khỏi tệp PDF, và tài liệu giả định rằng phông dùng để render có cùng metric với các kiểu chữ truyền thống như Times, Helvetica, Courier
Vì vậy nếu dùng phông hệ thống tương thích, bố cục tài liệu sau khi render không nên thay đổi. Tất nhiên vẫn có những trường hợp phông hệ thống được quảng bá là tương thích metric với các phông Adobe PostScript cũ nhưng lại có khác biệt tinh vi
Ngoài số ít phông hệ thống tiêu chuẩn, tài liệu PDF thường chỉ bao gồm tập con glyph tương ứng với các ký tự thực sự dùng trong văn bản, chứ không phải toàn bộ phông đó
Sau hơn 20 năm nghĩ rằng PDF render nhất quán, mãi đến khi trong một buổi phỏng vấn có người nói tài liệu của mình trông kỳ lạ, mình mới biết là phông chữ có thể bị thiếu
Đó đúng là The Daily WTF ngoài đời thực
Tò mò không biết có phần mềm nào tối thiểu hóa phông chữ bằng cách loại bỏ các code point không dùng trong tài liệu không
1 bình luận
Ý kiến trên Hacker News
Tôi rất quan tâm đến giao điểm giữa ebook, bảo mật và web LowJS, nên chủ đề này có ý nghĩa quan trọng với tôi
Cần có một định dạng ebook di động dưới dạng một tệp duy nhất, nhưng PDF không phải câu trả lời vì không thể tái lưu chuyển văn bản
HTML+CSS của năm 2024 có thể tái hiện gần như mọi ấn phẩm in mà vẫn cho phép tái lưu chuyển văn bản
Tôi không nghĩ JavaScript nên là bắt buộc. Ebook phải là một cuốn sách có thể thay đổi kích thước một cách có ý nghĩa, và ngay cả khi tắt JavaScript, các chức năng cơ bản với tư cách là sách vẫn phải hoạt động. Nếu cần tương tác hoặc bổ sung thì có thể dùng JavaScript, nhưng nếu không có JavaScript mà nó không hoạt động như một cuốn sách thì tôi xem đó là lỗi
Tôi nghĩ đưa toàn bộ style vào inline là một sai lầm vì có thể phá vỡ CSP của một số người dùng. Nên tách style thành tài nguyên dùng đường dẫn tương đối theo HTML, và ebook phải cấm tải tài nguyên từ các domain khác
Cuối cùng, chỉ cần phân phối dưới dạng tệp zip là được. Tôi nghĩ ebook vốn đã hoạt động kiểu như vậy rồi không phải sao
Nhưng chiều ngược lại thì không nhất thiết đúng. Ngay cả khi cùng một bộ tệp là EPUB hợp lệ trước khi giải nén, nếu nén lại thành zip tùy tiện thì có thể không còn là EPUB hợp lệ
Tệp mimetype bên trong zip EPUB là đặc biệt: nó phải là mục đầu tiên trong archive, nội dung chỉ được là
application/epub+zip, và phải được lưu ở trạng thái không nénBất ngờ là nhiều công cụ zip khiến việc này phiền phức vì chúng đổi thứ tự tệp hoặc làm cho việc chỉ lưu một số tệp ở dạng không nén trở nên khó. Chương trình zip dòng lệnh thường làm được bằng cờ, nhưng trong thư viện zip thì khá đau đầu. Đây là kinh nghiệm từ việc từng làm phần mềm tạo EPUB
Thứ được mô tả chính là định dạng ePub, trong đó các tệp HTML, CSS và hình ảnh nằm trong một archive zip
Nó cũng bao gồm CSP để đảm bảo an toàn
Điểm mà các tệp .doc cũ dùng thích hơn .docx là trong một thư mục có hàng trăm đến hàng nghìn tệp, có thể tìm kiếm một từ cụ thể rất nhanh. Với định dạng zip thì không làm được điều đó
Tôi vừa lưu thành .doc rồi mở bằng trình chỉnh sửa hex, và thấy nội dung thực sự nằm ở dạng văn bản thuần. Định dạng zip hay tệp PDF khó tìm bằng grep, và tôi cũng nghi ngờ liệu vài nghìn ký tự văn bản có thật sự cần nén hay không
Đây là một bài viết rất bài bản của nhà phát triển Nota, nhằm đưa định dạng EPUB lên ngang tầm PDF. Họ đã làm cả trình xem, và bản thân bài viết cũng đang được hiển thị bằng bản port WASM chạy trên trình duyệt của trình xem đó
Một trong các vấn đề là EPUB, về thực chất là XHTML, có thể tái hiện bố cục chính xác đến mức nào. Tiêu chí trong bài gốc là tài liệu trông “hợp lý”, nhưng để sánh với PDF thì có vẻ ít nhất HTML cần các tính năng bố cục mới ở phần ngắt dòng
Tôi thấy có hai hướng tiến lên. Một là trình duyệt cung cấp nhiều công cụ typography hơn;
text-wrap: prettyđược nói là có ích, nhưng khi tôi thử nhanh thì không thấy chất lượng ngắt dòng tốt hơn. Hướng còn lại là tính trước việc ngắt dòng, nhưng điều này chỉ khả thi với rendering bố cục cố địnhNgoài ra, tác giả có nhắc đến chú thích, nhưng tôi không rõ họ định triển khai như thế nào
Điều này đã khả thi trong EPUB3, nhưng nhược điểm là trên các màn hình như điện thoại thì trông không đẹp. Tùy trình đọc, có thể ghi đè các giá trị mặc định, nhưng khi đó phải kỳ vọng trình đọc tái tạo lại tài liệu sao cho đẹp
Một phương án thay thế là EPUB chỉ định nhiều bản render cho các kiểu màn hình phổ biến. Dù không hoàn hảo, việc để người tạo tài liệu cung cấp mặc định và cho phép người dùng ghi đè nếu muốn có vẻ là một thỏa hiệp tốt
Thứ một định dạng ebook cần là markup ngữ nghĩa thích ứng với thiết bị render. HTML+CSS vốn được tạo ra cho mục đích đó
Vì vậy, người thiết kế bố cục sách phải có ý thức trao một phần quyền kiểm soát việc cuốn sách trông thế nào cho độc giả. Một chút không hoàn hảo về thị giác là cái giá đáng trả. Nếu cần sự hoàn hảo về thị giác thì dùng PDF
Tất nhiên, khi có yếu tố tương tác thì sẽ khó hơn. Có lẽ tốt nhất là các yếu tố tương tác lớn mở trong một chế độ xem chuyên dụng khi cần, còn các yếu tố tương tác nhỏ thì chấp nhận tái lưu chuyển
Tôi nghĩ chú thích và tham chiếu vốn đã có trong đặc tả EPUB, có khi cả đặc tả HTML nữa
Tôi cũng không đồng ý rằng cách nhấn giữ để hiện popup tốt hơn anchor hyperlink thông thường. Nếu chức năng “quay lại” của trình đọc hoạt động đúng, hoặc tham chiếu hai chiều có liên kết “quay lại”, thì cách điều hướng sẽ ít gây gián đoạn hơn nhiều
Ý tưởng là phân phối tài liệu XML cùng với stylesheet XSL, chuyển đổi thành FO để render, và có thể có nhiều stylesheet cho cùng một tài liệu tùy theo thiết bị đích hoặc kích thước trang
Trong Firefox, tôi dùng tiện ích SinglePage để lưu DOM của trang hiện tại thành một tệp HTML độc lập. Cách làm là nhúng inline CSS và URL
data:cho hình ảnh, rồi loại bỏ các phụ thuộc và scriptKhông hoàn hảo, và tôi cũng không tin rằng trình duyệt sẽ luôn duy trì tương thích ngược, nhưng tôi thích cách này hơn việc lưu trang thành PDF hoặc thành nhiều tệp
Thú vị là một trong số ít trang mà tiện ích này thất bại lại chính là bài viết này về EPUB di động. Có vẻ như đã có quá nhiều “ma thuật” để căn chỉnh định dạng. Trang đã lưu vẫn đọc được, nhưng style thì hoàn toàn khác bản gốc
Tôi thích việc fbreader trên Android hiển thị mọi cuốn sách giống nhau theo thiết lập của ứng dụng, thay vì theo style của tệp EPUB. Tôi chưa từng thấy nó áp dụng CSS hay cố chạy script có trong tệp, và hy vọng sau này cũng không như vậy. Tải các phụ thuộc bên ngoài còn là ý tưởng tệ hơn, và ngay từ đầu tôi cũng không biết là việc đó được cho phép
Nhân tiện chuyện đó, hệ thống quyền của tiện ích Firefox khá kỳ lạ. Để làm được việc gì thú vị thì gần như phải yêu cầu mọi quyền, và kết quả là hình thành một thị trường tự nhiên cho những kẻ độc hại đi săn mua các tiện ích để tiếp quản
Ví dụ, tiện ích SingleFile đúng là cần quyền truy cập vì nó phải nhìn vào DOM đã render rồi lưu thành tệp. Nhưng tại sao nó lại phải truy cập mọi thứ? Không thể chỉ cấp các quyền kiểu
snapshot DOM once,write to a single filethôi saoKhi đó có lẽ tôi cũng không giải thích được lý do cho rõ, thậm chí cũng chưa hiểu hết, nhưng mong muốn ấy bị xem như điều vô lý. Giờ nhìn lại, có vẻ tôi chỉ lệch thời khoảng 10 năm, nên thấy khá vui
KOReader kém thân thiện hơn nhưng cho nhiều quyền kiểm soát hơn. Bạn có thể chọn một tệp cụ thể trong số nhiều tệp CSS được cung cấp, hoặc tự viết CSS của mình
Điểm mạnh của KOReader còn có hỗ trợ OPDS xuất sắc và máy chủ đồng bộ tự host dễ thiết lập
Khi có tính năng này, các trang dùng hệ thống này sẽ không cần SinglePage nữa
Nhìn phần đó rồi tôi đã xem lại. Đó là đoạn: “Vì vậy, chúng tôi quyết định tạo Bene, một hệ thống đọc EPUB nhẹ hơn. Đây chính là thứ các bạn đang dùng. Tài liệu này là một EPUB, và có thể tải xuống bằng cách nhấn nút ở góc trên bên phải”
Khi đọc trên trình duyệt desktop, tôi hoàn toàn không nhận ra cho đến khi được chỉ trực tiếp. Trên di động thì phần header chiếm nhiều màn hình hơn nên dễ thấy hơn, nhưng ngoài chuyện đó ra nó hoạt động gần như một trang web bình thường
Có lẽ đó là một tín hiệu tốt
Trái với một số bình luận đã nói, khi tải tài liệu lần đầu tôi không thấy, hoặc ít nhất là không để ý thấy, spinner. Trên điện thoại thì có thấy, nhưng nó trôi qua khá nhanh. Tôi không biết đó có phải là lúc tải chương trình WASM hay chỉ xảy ra ở lần tải đầu tiên không
Khác với trang web thông thường hay PDF, có vẻ như việc render không bắt đầu cho đến khi toàn bộ tài nguyên, tức toàn bộ ePub, được tải xuống
Một khác biệt mà tôi tưởng bài viết sẽ đề cập nhưng lại không nói đến là hiệu năng. PDF có thể được tối ưu để các trang khá độc lập với nhau, cho phép render tăng dần, truy cập ngẫu nhiên và song song hóa cao
Chỉ riêng việc trình duyệt không mở được EPUB đã khiến dự án này có cảm giác như phần nào đã được định sẵn là sẽ thất bại. Với PDF, nếu liên kết tới thì dù có chút chuyển ngữ cảnh, trình duyệt vẫn mở và hiển thị được
EPUB, theo mô tả, về cơ bản là HTML, nên việc trình duyệt không mở được là lạ, nhưng có vẻ sẽ không dễ thuyết phục các quan chức ở Chrome/Mozilla
Một điểm đáng nản nữa là HTML và CSS đã trở nên quá khổng lồ và cồng kềnh, đến mức gần như không còn mấy ai có thể triển khai một “trình đọc” cho EPUB/HTML. Về cơ bản nó trở thành “hãy triển khai một trình duyệt mới”. Về dài hạn, cách dùng một Markdown dễ phân tích cú pháp như Djot rồi thêm chút khả năng render có vẻ khả thi hơn
Phương án thỏa hiệp tạm thời của cá nhân tôi là đưa toàn bộ CSS, SVG, script, thậm chí ảnh base64 vào một file HTML duy nhất. Nó tương tự EPUB, hơi cồng kềnh và xấu xí, nhưng chỉ cần để ý một chút là chạy được và trình duyệt có thể mở một cách tự nhiên
Tuy nhiên người dùng không có cách nào biết rằng “mình có thể tải trang web này xuống và lưu ngoại tuyến”. Sẽ hay nếu có một phần mở rộng như
.htmlsđể biểu thị đây là HTML không có tài nguyên bên ngoàiCó vẻ không có lý do gì trình duyệt không thể làm điều tương tự với EPUB. Đã có tiện ích mở rộng trình duyệt làm đúng việc đó rồi. Vấn đề là định dạng EPUB có đạt được độ phổ biến hay không
Rồi thiết kế và bố cục kiểu tạp chí trở nên “cần thiết”, nhưng vì vẫn dựa trên tài liệu nên cũng khá ổn
Sau đó người ta cố nhồi HTML vào vai trò nền tảng phân phối ứng dụng. Bố cục CSS hiện nay cuối cùng đã gần hơn với các engine bố cục ứng dụng truyền thống
Tôi cho rằng 20 năm qua phần lớn đã bị lãng phí vì không có một cách phân phối ứng dụng đa nền tảng phù hợp. Ngoại trừ Java
Để định dạng này hoạt động có thể lặp lại ở mọi nơi, nó phải được chuẩn hóa và cũng phải dễ triển khai engine render mới. Cách phụ thuộc vào webview không có vẻ là con đường tiến lên
Vẻ đẹp của PDF nằm ở chỗ nó rất đáng tin cậy. Một file PDF từ 10 năm trước hôm nay vẫn được render y như trước
Để nỗ lực kiểu này thành công, có lẽ cần thu hẹp phạm vi tài liệu rất nhiều. Tập con XHTML được phép phải rất hạn chế, và phải ưu tiên khả năng render giống nhau ở mọi nơi. Trước hết nên là bố cục cố định với kích thước trang cố định, sau đó mới đến tài liệu có thể reflow. Cũng cần một tiêu chuẩn có các tài liệu kiểm thử toàn diện và đầu ra render đi kèm
Nếu không có hỗ trợ từ trình duyệt, việc viết một proxy phía máy chủ để biến EPUB thành một site có thể duyệt, kèm điều khiển chuyển chương và một vài tùy chọn bố cục đơn giản, có lẽ không quá khó
Dĩ nhiên để xem phần lớn ebook thương mại bằng proxy như vậy, hỗ trợ DRM cần thiết rất có khả năng sẽ là vấn đề pháp lý nghiêm trọng
Nghĩ lại thì hỗ trợ EPUB DRM được nhà xuất bản chấp thuận trong trình duyệt về mặt kỹ thuật chỉ cách hỗ trợ DRM cho trang web thông thường nửa bước, và đó là một viễn cảnh khá kinh khủng
Tôi nghĩ PDF là một định dạng legacy tệ hại với độ phức tạp không cần thiết. Phần lớn cách dùng PDF không liên quan gì đến in ấn, nên logic dàn trang cũng không thuyết phục
Trong đa số trường hợp sử dụng, việc dễ đọc trên điện thoại, máy tính bảng và máy tính quan trọng hơn nhiều
Tác giả nói iBooks không hỗ trợ chế độ cuộn khiến tôi ngạc nhiên nên đã tự kiểm tra. iBooks trên macOS không hỗ trợ cuộn file ePub, nhưng trên iOS và iPadOS thì có. Một quyết định rất kỳ lạ của Apple
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Tôi chưa từng thấy tài liệu kỹ thuật được phân phối ở định dạng không phải PDF mà lại tiện cho đọc và tìm kiếm. Trên điện thoại cũng vậy
Tôi không muốn tài liệu có hình thức thay đổi tùy theo trạng thái nhất thời như thiết bị đọc hay kích thước cửa sổ. Tôi muốn tài liệu có bố cục cố định do tác giả thiết kế tốt
Ngay cả khi đọc trên màn hình hoặc cửa sổ nhỏ, nếu đó không phải tài liệu văn bản thuần túy, tôi muốn một trình đọc thông minh giúp phóng to/thu nhỏ và di chuyển nhanh, chứ không phải thay đổi bố cục. Nó không nên có hành vi ngớ ngẩn như một số trình đọc Android, nơi cuộn dọc hoặc Page Up/Page Down lại làm dịch cả vị trí ngang, khiến việc đọc các cột văn bản trở nên khó khăn
Chỉ cần tuân thủ khuyến nghị truyền thống về độ rộng tối đa của cột văn bản là đã đủ để đọc thoải mái trên điện thoại. Việc đọc trên điện thoại chỉ trở nên khó chịu khi tác giả tạo cột quá rộng và phá vỡ các quy tắc typography truyền thống
Vì vậy, cố tạo một tiêu chuẩn duy nhất phù hợp với mọi thứ có vẻ là ý tưởng tệ. Tiêu chuẩn tài liệu số có lẽ nên có hai loại. Một loại là định dạng có đầy đủ khả năng đa phương tiện và tương tác, trừ networking; loại còn lại là một tập con của nó, giới hạn ở đen trắng, không có đa phương tiện, và tương tác chủ yếu chỉ ở mức siêu liên kết trong tài liệu
Và thực ra gần như đã có hai định dạng như vậy rồi. HTML, MHTML=EML, và EPUB
Tất nhiên cũng cần một định dạng thứ ba cho lưu trữ vật lý và các tài liệu số bố cục cố định hiếm gặp, và PDF/A có vẻ đã làm vai trò đó khá tốt
SVG nhiều trang có thể cũng khả thi, nhưng để in nhiều trang cho đúng, rốt cuộc có lẽ vẫn phải xuất sang PDF trước. Tôi nói vậy khi nhìn vào Inkscape
8 ngày trước có bài “Portable Web Documents – An Alternative to PDF Based on HTML5 (2019)” đạt 134 điểm
https://news.ycombinator.com/item?id=39036774
https://news.ycombinator.com/item?id=39037135
Mình tò mò trình đọc EPUB cung cấp gì mà trình duyệt không có. Nhìn hiện tại thì câu trả lời dường như chỉ có đúng một thứ, khá nhỏ: tệp .epub, tức là khả năng xử lý tệp zip như một thư mục
Nếu khác biệt giữa trình đọc EPUB và một tập con của trình duyệt thực sự chỉ có vậy, thì cách đơn giản nhất và ít tốn công nhất có lẽ là thế này
Cho các trình duyệt hiện có xử lý tệp zip như thư mục trong một số điều kiện nhất định
Định nghĩa một giới hạn HTML có thể kiểm tra bằng máy, bảo đảm tài nguyên hoàn toàn cục bộ như bài gốc nói. Chỉ cần yêu cầu mọi URL, ngoại trừ liên kết, phải là đường dẫn tương đối có thể đã đủ
Tuyên bố các tệp zip thỏa giới hạn này là “EPUB di động”
Quên hết các trình đọc EPUB chuyên dụng, dù cũ hay mới
Với tài nguyên hoàn toàn cục bộ, mình muốn thấy yêu cầu rằng mọi đối tượng đều phải có phương án thay thế khả dụng cục bộ. Kiểu như nếu không lấy được phông chữ đó thì dùng phông chuẩn. Có thể trông không hoàn hảo, nhưng nếu giới hạn trong phạm vi fallback thì nó vẫn nên hoạt động hợp lý
Có một chế độ lỗi vẫn chưa được xử lý đủ: hình ảnh không hoạt động đúng. Về cơ bản là vì hình ảnh không thể reflow. Phần lớn có thể giải quyết bằng cách dùng SVG, nhưng với hình raster thật thì không được. Cuối cùng có lẽ chỉ còn cách cung cấp vài độ phân giải khác nhau
Mình cũng gặp một vấn đề liên quan nhưng chưa thấy câu trả lời hay. Đó là SVG nhận biết độ phân giải và tải hình chi tiết hơn khi có đủ độ phân giải. Nếu vẽ các đường subpixel thì chúng bị mờ, nhưng khi phóng to cùng hình ảnh đó thì các đường ấy lại trở nên hữu ích. Biểu tượng Windows thừa nhận điều này bằng cách có thể chứa nhiều độ phân giải và dùng bản phù hợp với ngữ cảnh
Tác giả là nghiên cứu viên sau tiến sĩ dưới sự hướng dẫn của Shriram Krishnamurthi. Shriram Krishnamurthi là tác giả của Programming Languages: Application and Interpretation(PLAI) và là một trong các tác giả của Data-Centric Introduction to Computing(DCIC)
Hiện mình đang đọc cả PLAI lẫn DCIC, và thật sự ấn tượng trước sự chăm chút tỉ mỉ mà các tác giả đã bỏ ra để biến chúng thành những tác phẩm nghệ thuật phục vụ giáo dục. Đó đúng là tình yêu thật sự
https://willcrichton.net/
https://rust-book.cs.brown.edu/
PDF có thể nhúng phông chữ, nhưng thường không nhúng và phụ thuộc vào phông hệ thống. Một lý do là đưa phông chữ vào PDF có thể làm kích thước tệp tăng mạnh. Trong một số trường hợp, một phông chữ đơn lẻ có thể còn lớn hơn toàn bộ phần còn lại của tệp
Mình từng triển khai việc nhúng phông trong phần mềm tạo PDF, và việc tìm ra cách làm cho nó hoạt động ổn định hóa ra khó hơn tưởng tượng
Việc PDF được render nhất quán cũng không đúng như nhiều người nghĩ. Nhiều lần cùng một PDF render khác nhau tùy trình xem PDF được dùng. Thường khác biệt rất tinh vi, nhưng đôi khi cũng có các trường hợp biên khác biệt khá lớn. Mình cũng từng gặp trường hợp cùng một phiên bản Acrobat Reader render PDF khác nhau tùy hệ điều hành
Vì vậy nếu dùng phông hệ thống tương thích, bố cục tài liệu sau khi render không nên thay đổi. Tất nhiên vẫn có những trường hợp phông hệ thống được quảng bá là tương thích metric với các phông Adobe PostScript cũ nhưng lại có khác biệt tinh vi
Ngoài số ít phông hệ thống tiêu chuẩn, tài liệu PDF thường chỉ bao gồm tập con glyph tương ứng với các ký tự thực sự dùng trong văn bản, chứ không phải toàn bộ phông đó
Đó đúng là The Daily WTF ngoài đời thực