|
|
Rank: Newbie
Groups: Member
Joined: 12/5/2019
Posts: 5
|
I have a PDF with form fields that I want to populate from code. The fields have a font of 'Times New Roman'. When I access the fields in the PDF with the PdfDocument.Fields property, they all show as having a font of 'Arial'. If I don't change the values of the fields they properly output with a font of 'Times New Roman', but if I change the values they output as 'Arial'. If I set the font name to 'Times New Roman' in code it renders properly, but that seems like a workaround to a bug. I also won't always know what font the field needs to be set to once my code is used for other PDFs. Here's the relevant code:
Code: C#
var report = new PdfDocument("Invoice.pdf");
foreach (var field in report.Fields)
{
field.Value = field.FullName; //This line causes the font to change
//field.Font.Name = "Times New Roman"; //Workaround code to change the font back
field.ReadOnly = true;
}
report.Save("Report.pdf");
Any assistance you can provide would be welcome.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
This is due to the fact that the a textbox field in fact can have two separate font settings: one font for displaying the text when the text box is not active, and another font for editing the text when the textbox is active. The issue you see can occur when these two fonts are set differently, or only one of them are set. When you only fill in the value (or change an existing value), we try to touch as less as possible in order to preserve whatever settings already in your PDF file as much as possible. If you try to force set field.Fontn.Name, then we know you really do want to set the font and we would save the new value to both.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 12/5/2019
Posts: 5
|
My issue is with the font being changed without me changing it. The font is set to 'Times New Roman', but when I use EO to set the field.Value (Not the font) the font is changed to 'Arial'. If I don't use EO to change anything about the field it renders with the correct font (Times New Roman). This has nothing to do with the field being 'active' or not. So to be clear, this code results in fields with the wrong font:
Code: C#
foreach (var field in report.Fields)
{
field.Value = field.FullName; //This line causes the font to change
field.ReadOnly = true;
}
But this code gives the correct font:
Code: C#
foreach (var field in report.Fields)
{
field.ReadOnly = true;
}
Note that neither block of code attempts to change the font in any way. Yet the first block does in fact change it. I need to be able to update the field.Value property without the font being changed on me by EO.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi, Can you send the PDF file and a small test code to us? See here for more details on sending test files to us: https://www.essentialobjects.com/forum/test_project.aspxOnce we have that we will look into it and see what we can find. Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 12/5/2019
Posts: 5
|
I sent in a simple test project with a subject line matching the title of this topic.
You noted in your first reply that PDF form fields have two fonts; one for when the field is active, and one for when it's inactive. If that is the case, why can only one of them be set with EO.Pdf? Wouldn't it make more sense to allow both fonts to be set independently? Also, if there are two fonts, which one is used to populate the field.Font property on the fields? The active one or the inactive one? I would hope it's the inactive one since it's the one that would be shown most of the time.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
We have looked into the file you sent to us. There is indeed an issue on our end. The root of the issue for this case is not directly related to two different fonts, but to font subset. Here are the background information:
1. In order to guarantee that a PDF file can be displayed on a target system without the specific font used, PDF typically embed the font data inside the PDF file;
2. The embedded fonts are often a subset. A font subset is a font that only contains information on a subset of characters. So for example, in your first field, it has value "ComicSans" and the "Appearance" font for this field only contains information about these letters. PDF stores font data this way in order to reduce the file size;
3. If the value of this field is changed to something else and the corresponding font is not modified, then the newly added letters may not be displayed properly. As such modifying a field's value requiring modifying it's "Appearance" font;
We did find an issue with our code when modifying the font when it's a subset. This will be fixed in our next build.
As to the two fonts, our take is even though PDF defined two separate fonts for a single PdfTextField, in reality very few people really want to use two separate fonts on a single text field. Exposing both fonts can cause significant confusion and inconvenience for our users. As such we only exposes a single Font property to the end user.
The internal logic to handle the two fonts are:
1. When reading Font property, if both inactive font and active font are set, inactive font takes priority (because that's the font used when user just opening the file without having to focus the textbox first);
2. When writing Font property, the same value are applied to both;
Hope this helps. We will reply here again once the new build is available.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 12/5/2019
Posts: 5
|
This font subset behaviour seems like it could be problematic. I understand that it isn't something you control, but do you know of any way I can work around it to force the entire font to be included? I assume making the field initially contain every character I would ever use would work, but it feels like a 'brute force' approach. Is there a more elegant solution to this?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
There is no way you can force the entire font to be included. This can be awfully inefficient for font that covers large number of characters. For example, Microsoft MingLiu Chinese font is over 30M.
This only becomes an issue with textbox field because there is no way to anticipate what characters the user will enter. The recommend method to avoid such issue is to only use one of the so called "standard 14" fonts for textboxes. These are fonts that the specification states that all conforming PDF Viewer application must be able to render properly even without embed font data (thus these 14 fonts do not have to be embedded in the PDF file itself). However most PDF Viewer can handle common fonts such as Arial without any issue even though it is not in standard 14 fonts. So the idea is do not use any "special" font for textboxes.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 12/5/2019
Posts: 5
|
Hello,
Is there any progress with fixing this issue? I assume the holidays have slowed things down, which is fine. I just need to provide an update to my employer on the status of the fix.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Thank you very much for your patience. We did fix this issue on our end, but the fix will be in our new 2020 release and we are still about two weeks away from this release.
|
|