We Keep Coding

Regd. The font 'ABCDEE+Calibri' contains bad/widts on Unix/Linux

Greetings for the Day :)
I am working on PdfBox and generated PDF successfully as per requirement on Windows. But when running my solution on Unix/Linux and it is generating the PDFs as per requirement. When we tried to open the PDF with Adobe Acrobat Reader DC version it is giving Pop-up The font 'ABCDEE+Calibri' contains bad/widts. I moved the PDF to windows from linux and tried to open the pdf , now its poping up on windows as well. I have not used calibri anywhere on my pdf. I used TrueTypeFont to load.ttc file as .ttf file. Apart from that there is no great logic as well.
Map<String, PDFont> suppFonts = new HashMap<>();
PDFont arial = PDType0Font.load(pddoc, <<className>>.class.getResourceAsStream("/path/to/the/file.ttf").getInputStream());
PDFont mingliu = PDType0Font.load(pddoc, new TrueTypeCollection(<<className>>.class.getResourceAsStream("/path/to/the/file.ttc").getInputStream());
suppFonts .put("arial",arial);
suppFonts .put("mingliu",mingliu);
we used this HashMap and retrieved font with the name we have given such as arial,mingliu..etc.
Please help me if you have faced such kind of issue earlier.

JAVA - font path instead font name in docx

I am using Apache POI to generate .docx document. I added external fonts to my project. For example:
String playfairDisplayRegular = this.getClass().getClassLoader().getResource("PlayfairDisplay-Regular.ttf").getFile();
I used playfairDisplayRegular in paragraph. When I mark text in the document in the field with the name of the font is path for example:
/C:/Users/..../Documents...
instead of the font name (the font is working). Any ideas ?
Greetings, Artur

URL.getFile() just returns the file name part (+ optional query part ?...) of the URL.
For resources (files possibly inside a jar, residing on the class path) one should rather not use File, but use an InputStream, whenever possible.
With java.awt.Font:
Font font = Font.createFont(Font.TRUETYPE_FONT,
getClass().getResourceAsStream("/PlayfairDisplay-Regular.ttf"));
In the docx you can now use font.getFamily() (for XSLFTextRun.setFontFamily) and such.
Embedding fonts in the docx:
Meanwhile apache poi might be able to embed fonts (license issue for you!), but doing it yourself should be simple: .docx is a zip format, fonts are in a /fonts/ subdirectory. You can test it in a small docx written in MSWord. Writing the file can be done by a zip file system: "jar:file:/C:/... .docx", and Files.copy.

Using java.awt.Font will be problematic for me, bacause my syntax looks like this:
printParagraph(createParagraphWithAlignment(document, ParagraphAlignment.RIGHT),
"something",
new Font(playfairDisplayRegular, 12, Boolean.TRUE, Boolean.FALSE));
And methods used:
protected XWPFRun printParagraph(XWPFParagraph paragraph, String text, Font font) {
XWPFRun run = paragraph.createRun();
run.setText(text);
run.setFontSize(font.getSize());
run.setBold(font.getBold());
run.setItalic(font.getItalic());
run.setFontFamily(font.getName());
return run;
}
protected XWPFParagraph createParagraphWithAlignment(IBody ibody, ParagraphAlignment alignment) {
XWPFParagraph paragraph = castParagraph(ibody);
paragraph.setAlignment(alignment);
return paragraph;
}

Why do my custom fonts work from Eclipse, but not from an exported JAR?

I am trying to hack together a game in Java, and on the start screen I used a custom font I downloaded. When I run the program from Eclipse, the screen looks like this (just as it should):
However, when I run the program from the compiled jar, the screen looks like this:
Here is my code for loading the font:
title = new JLabel("philip k. dick"); // font requires all lowercase
try {
Font f = Font.createFont(Font.TRUETYPE_FONT, new File(Util.getFile("all used up.ttf")));
title.setFont(new Font(f.getName(), f.getStyle(), 150));
} catch (Exception e) {
e.printStackTrace();
Font oldFont = title.getFont();
title.setFont(new Font(oldFont.getName(), oldFont.getStyle(), 100));
}
The method Util.getFile just adds "resources/" to the beginning of the given String.
There are no errors given when I run the jar from the command line. I know that the program can access the font resource because when I rename the "resources" folder (to prevent access), the screen looks like this:
Additionally, I get this error:
java.io.IOException: Can't read resources/all used up.ttf
Of course, THIS is expected.
I would also like to note that I have other audio and image resources being loaded from the same location, and they work fine. This location is in the folder directly outside of the jar. Also, I am using a Mac, but I get the same problem on Windows.

The contents of your resources directly are typically add to your Jar.
This means that they can no longer be access using a File object, as they are actually now part of a Zip file.
You need to use something like getClass().getResource(...) to it up. This returns an instance of URL which points to the resource (if it can be found)
However, Font.createFont takes either a File or InputStream reference, in this case you should use getClass().getResourceAsInputStream(...), something like...
Font f = Font.createFont(Font.TRUETYPE_FONT, getClass().getResourceAsInputStream("resources/all used up.ttf"));
This makes a "relative" path request from the context of the class trying to load the resource. This is probably not going to work, so instead, you could use
getClass().getResourceAsInputStream("/resources/all used up.ttf")
Which creates an absolute path lookup from the context of the classpath
If you get stuck, try unpacking the Jar and see if the font resides within and where and make adjusts as required.
Updated...
Try using...
Font f = Font.createFont(Font.TRUETYPE_FONT, new File("resources/all used up.ttf"));
title.setFont(f.deriveFont(150f));
As I understand it, new Font(...) is trying to find the font from the available system fonts.
From the Java Docs for Font#createFont...
This base font can then be used with the deriveFont methods in this
class to derive new Font objects with varying sizes, styles,
transforms and font features. ...To make the Font available to Font
constructors the
returned Font must be registered in the GraphicsEnviroment by calling
registerFont(Font).

Embedding font in a Java program using iText

I want to embed font into my Java program and I know how to do it using standard Java libraries. However, how do I do it using iText?
I don't want anything outside of my project (or later jar file) to be tampered with if it's not absolutely necessary (I want my program to work on all Java supporting platforms).
I'm importing font using *.ttf file.

Define a font
public static String[] FONT =
{"path/to/fonts/xxx.ttf", BaseFont.WINANSI};
then use
BaseFont bf = BaseFont.createFont(FONT[0], FONT[1], BaseFont.EMBEDDED);
Font font = new Font(bf, 24);
with the document.

Get font file as a File object or get its path

I have a Font object in Java for a font file. I need to convert that object to a File object or get the font file path.
Is there a way to do this?
What I'm doing here is calling a method from an external library that loads a font file to use it in writing:
loadTTF(PDDocument pdfFile, File fontfile);
So I wanted to let the user choose a font from the ones defined in his operating system using :
GraphicsEnvironment e = GraphicsEnvironment.getLocalGraphicsEnvironment();
Font[] fonts = e.getAllFonts();
Then when the user chooses a font, I pass it to the loadTTF(...) method to load it.
Is there a bad practice here?

// use reflection on Font2D (<B>PhysicalFont.platName</B>) e.g.
Font f = new Font("Courier New", 0, 10);
Font2D f2d = FontManager.findFont2D(f.getFontName(), f.getStyle(),
FontManager.LOGICAL_FALLBACK).handle.font2D;
Field platName = PhysicalFont.class.getDeclaredField("platName");
platName.setAccessible(true);
String fontPath = (String)platName.get(f2d);
platName.setAccessible(false);
// that's it..
System.out.println(fontPath);

Ok ... This will return the font file path :
String fontFilePath = FontManager.getFontPath( true ) + "/" + FontManager.getFileNameForFontName( fontName );
I have tried this in Windows and Linux and in both it worked fine.

No.
A Font in Java is just a representation and definition of how characters can be displayed graphically. It has nothing to do with the filesystem, and technically need not even be ultimately defined in a file (see for example the createFont() method that takes an arbitrary input stream, which could come from anywhere e.g. a network socket). In any case, it would certainly be a ridiculous break in abstraction for you to be able to get the path of the underlying system file that defines the font.
I would suggest that you might be doing the wrong thing in your other method if you're relying on accepting a file. Or if this really is needed, then you're doing the wrong thing in this method by thinking that a Font object has a simple correlation to an underlying file. If you really need to get the file path of a particular font you'll need to approach it from a different angle that doesn't involve java.awt.Font.