Non-styled versions of TTF fonts are chosen and artificially styled over available styled versions
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Start by tracing how FontFactory.register and FontFactory.getFont handle the registered Roboto style names and the supplied style flags. The report provides a Java reproduction using regular, italic, bold, and bold-italic TTF files, but names no source file or test. Done means the italic and bold-italic requests use their matching font files and render with the expected weight and angle.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Describe the bug
I'm observing something similiar to what #244 described: I'm registering a bunch of TTF files (Roboto) in different styles from the class path and trying to use these. However, OpenPDF seems to choose the regular (non-styled) font file and apply all necessary styles to it instead of using the styled version in the first place.
To Reproduce
Put the Roboto files (regular, italic, bold, bold-italic; downloadable from Google Fonts) onto the classpath (e.g., the resources folder when using maven) and register them like so:
// In a class file
private static final Font ROBOTO_BOLD_ITALIC;
private static final Font ROBOTO_BOLD;
private static final Font ROBOTO_ITALIC;
private static final Font ROBOTO_REGULAR;
static {
URL robotoRegularUrl = Thread.currentThread ().getContextClassLoader ().getResource ("fonts/Roboto-Regular.ttf");
URL robotoBoldUrl = Thread.currentThread ().getContextClassLoader ().getResource ("fonts/Roboto-Bold.ttf");
URL robotoItalicUrl = Thread.currentThread ().getContextClassLoader ().getResource ("fonts/Roboto-Italic.ttf");
URL robotoBoldItalicUrl = Thread.currentThread ().getContextClassLoader ().getResource ("fonts/Roboto-BoldItalic.ttf");
// Obviously check if any of those URLs is null
try {
FontFactory.register (robotoBoldItalicUrl.toExternalForm (), "Roboto-BoldItalic");
FontFactory.register (robotoItalicUrl.toExternalForm (), "Roboto-Italic");
FontFactory.register (robotoBoldUrl.toExternalForm (), "Roboto-Bold");
FontFactory.register (robotoRegularUrl.toExternalForm (), "Roboto");
ROBOTO_BOLD_ITALIC = FontFactory.getFont ("Roboto-BoldItalic", BaseFont.IDENTITY_H, true, 10, Font.BOLDITALIC);
ROBOTO_BOLD = FontFactory.getFont ("Roboto-Bold", BaseFont.IDENTITY_H, true, 10);
ROBOTO_ITALIC = FontFactory.getFont ("Roboto-Italic", BaseFont.IDENTITY_H, true, 10);
ROBOTO_REGULAR = FontFactory.getFont ("Roboto", BaseFont.IDENTITY_H, true, 10);
} catch (Exception e) {
e.printStackTrace ();
throw new IllegalStateException (e);
}
}
This will lead to all files being read. Using them like new Paragraph ("text", ROBOTO_BOLD_ITALIC); will (apparently) not use the file previously read, but rather the regular one and OpenPDF will apply all given styles to that one. This is judging by the looks of the outcome, it looks just like the PDF displayed in #244.
Curiously, if I don't specify styles at all in FontFactory.getFont, then OpenPDF will only use ROBOTO_REGULAR whenever ROBOTO_ITALIC or ROBOTO_BOLD_ITALIC should have been used. ROBOTO_BOLD works as expected though.
Expected behavior
Italic and Bold-Italic should work as expected, using the correct file supplied for them.
Screenshots
This is produced by OpenPDF:
This is as displayed in-browser on Google Fonts:
This is as displayed in LibreOffice:
Obviously, OpenPDF's output looks just wrong: Notice the stroke weight and inclination angle.
System
- OS: Linux (OpenSuSE Tumbleweed)
- Used font: Roboto
- OpenPDF version: 2.0.1 (cannot upgrade due to this issue)
- Ngôn ngữ chính
- Java
- Star
- 4.4k
- Fork
- 714
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của LibrePDF/OpenPDF
-
bug
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
-
IndexOutOfBoundsException in PdfReaderCó thể đã có người làm @andreasrosdalw đã nhận 94 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
`PdfSmartCopy` can take effectively unbounded time on nested shared Form XObjectsCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởbug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 38/100
Tất cả issue của LibrePDF/OpenPDF
Issue tương tự
-
Update samples to Citrus 5.1.0Có thể đã có người làm @asuruceanu đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
snowflakedb/snowflake-kafka-connector#1610 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
add multipart/form-data exampleĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
swagger-api/swagger-petstore#245 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
liquid-java/liquidjava#443 ·
Maintainer thường phản hồi trong vòng 2 ngày