I'm running wkhtmltopdf on linux server (centos.10.x86_64). I'm trying to add "Times New Roman" font to the page. I see the fonts but on some font sizes it adds spaces between the letters. I tried setting the font by installing it on the machine (ttf) or by calling an external odf that I converted from the ttf or by adding it with base64 (css). It looks good on all, but it inserts spaces between the laters. I also tried to the dpi parameter but still the spaces are generated.
Generating the same pdf over MAC works perfectly (probably because the font comes with the machine)
Why does it happen and how can it be fixed ?
Thanks.
The image attached describes the bug. No spaces added in each of the fonts group.
The following the image text
abcdefg hijklmno pqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ
Was resolved using "svg" font format
Related
I'm currently working on a project that can convert HTML canvas to PDF, user can select the font and draw the text in the canvas and export as a PDF(vector), but there's a problem that user can enter other language text that the font doesn't really support it. It's shown fine in the canvas because the browser did the font fallback mechanism maybe to grab the system font as a fallback, but in the exported PDF it's all corrupted. I've embedded the font in the PDF but the font doesn't have corresponding glyph, and the PDF reader like adobe doesn't have font fallback mechanism so it all become .nodef
I have two ideas but that aren't really satisfying.
1. Collect all glyph from each sentence and create a new font
Walk through each char and check if current font has corresponding glyph, if so, adding it to the new font list, if not, using an alternative font from the font stack #1 as the fallback to get the glyph and adding it to the new font list, then finally converting it as a new font and embedding it in the new PDF.
It seems good but in reality the performance of generating new font is terrible.
(I was using Opentype.js to load and write a new font, when we exported the font by using toArrayBuffer method, it took 10 mins for 6,000 words)
#1, Font stack is a stack like ['Crimson Text', 'Pt Sans', 'Noto Sans'], if the first font can't find corresponding glyph then go next until the end we give up.
2. If encountered any missing char, change the font-family of that sentence to Arial Unicode MS or Noto
It's pretty simple but it converts every word in the sentence to Arial Unicode MS or Noto, besides, it's hard to find a good font that contains most of language's glyph and we can't use font stack mechanism because we only can use one font in one sentence.
My goal is to make the exported PDF similar with the canvas that user drew, hoping someone can give me some direction 😥, many thanks
The usual solution would be to embed all four fonts in your stack plus noto (all suitably subsetted, preferably), and switch between them mid-word as required.
Building a new frankenfont from the fonts as you suggest is not required, though I admire the ambition!
I'm trying to use Adobe Normalizer to convert PostScript files to PDF/A.
The problem I am having is that if a font isn't found it is a hard stop. I added the "--ignorestdttfonts=off" and that helps a little bit. Here's what I'm using for my command string:
demonorm -efi --ignorestdttfonts=off -r0 -P ICCProfiles\ -B ".\Settings\PDFA1b 2005 RGB.joboptions" +n -O -O c:\NormalizerOutput InputPsFile.ps
I am using /Times-Roman in my PostScript file, and I have times.ttf as an installed font, but I am getting this error:
%%[ Error: Times-Roman not found. Font cannot be embedded. ]%%
So I have 2 questions:
Given a TTF file, how do I know exactly what font name to use for
Adobe Normalizer?
How do I substitute a font when a font is not found? The default is
to use Courier, but that doesn't seem to be happening. I explicitly
added "--allowdefaultfont=on --defaultfont=Courier" but it had no
effect.
Adobe Normalizer will always look for the PostScript font name. Unfortunately unlike other Adobe products it will not create a fontlist (.lst) file where you can easily see the "FontName" and the location of the font file on your system. So you will have to find other ways to get the exact PostScript font name.
An easy way to see PostScript font names is to open the Distiller settings file (joboptions) using Distiller. You want to use Distiller because you want this to open in a GUI. On the left side panel select "Fonts" and under Embedding > Font Source > select C:\WINDOWS\Fonts\ (assuming the TTF file is installed here). The window below will list all the fonts in the C:\Windows\Fonts location. The fonts are listed by their PostScript font names. Note that PostScript font names do not appear with spaces. Look for the Times or Times Roman font that you have installed.
This does get quite tricky with Times or Times-Roman. Is your PostScript file (input file) referring to an Type1 or TrueType font?
In the Normalizer documentation (p174) the Times or Times New Roman family appears as:
Times
Times-Bold
Times-BoldItalic
Times-Italic
Times-Roman
Times New Roman
TimesNewRomanPS-BoldItalicMT
TimesNewRomanPS-BoldMT
TimesNewRomanPS-ItalicMT
TimesNewRomanPSMT
Note that Times and Times New Roman are not the same fonts. Times is a Type1 font and if you do not have this font installed on your system then Normalizer is correct in its error "Times-Roman not found. Font cannot be embedded."
Hope this information helps.
Adobe Normalizer, as I understand it (I don't have a copy) is essentially a server version of Acrobat Distiller. It accepts PostScript as an input and delivers PDF files.
So there are several possibilities:
1) Normalizer cannot use TrueType fonts installed on the server. From your description that doesn't seem to be the case, as you say that --ignorestdttfonts 'helps a little bit' (it might be useful to know what improves...)
2) Because the missing font is Times-Roman, its simply not embedding the font because it doesn't need to. The 'base 14' fonts are assumed to be included with any PDF consumer, and they don't need to be included. To be honest, this seems like the most likely, as I would have thought that Adobe would ship the base 14 fonts with the Normalizer.
3) The TrueType font isn't available to Normalizer. You haven't said how you installed times.ttf. Did you just install it on the OS (and what OS are you using anyway ?) or did you add it to Normalizer in some fashion ?
4) You may (as you think) have the font name incorrect. The problem is that you cannot use TrueType fonts directly in PostScript. In order to be used in a PostScript program they have to be converted into type 42 fonts. It may be that Normalizer simply can't do that. Do you have any reason to think it can ? If it can, then it may require a TrueType POST table, which is optional and may not be present in your font. However, the font name would be the same as the TrueType font name. The times.ttf I have is called "Times New Roman" and is in fact an OpenType font. If you want to use a font name with spaces you will have to make a string and convert to name :
(Times New Roman) cvn findfont
If you want to check the operation of the default font, I would suggest using a font name which is not one of the base 14, eg:
%!PS
/NoSuchFont findfont 20 scalefont setfont
10 10 moveto
(Hello World) show
showpage
Run that through Normalizer and see what comes out as the font. It may well be that it simply leaves the font request in place of course.
Finally; since this is a commercial product I assume you are entitled to support, wouldn't it be simpler just to ask Adobe ?
I have created a report using Pentaho Report Designer 3.9.1 and it contains Japanese characters. When I try to export the report into PDF, I am not getting the Japanese characters in PDF. Instead of Japanese characters it's showing as empty in PDF.
When I try to export into Excel, Japanese characters are displaying.
It is known that built-in fonts of the JDK are mapped to built-in fonts ( SANS-SERIF, SERIF OR ANY OTHER BUILT-IN FONT) of the PDF standard and that these fonts do not support anything other than western-european languages.
These fonts are not defined to include any Japanese characters as Japanese is not a western european language. If you use a font that does not include Japanese characters, you cannot expect it to display these characters.
Configuration that is needed is in PRD.
Click on File | Configuration
Click on 'output-pageable-pdf'
Set '~.EmbededFonts' to True
Set '~.Encoding' to UTF-8
The reason behing the japanese font working with PDF because, if you are using a metadata as the datasource, the metadata fonts for that field will be having a default font set one say example "Arial-10". You will have to edit the font there or you will have to manually override it in the report designer by setting the "data-format and the style-format" to false.
To get the result in BAServer:
Stop BA Server.
Browse to this file:
\biserver-ee\tomcat\webapps\pentaho\WEB-INF\classes\classic-engine.properties
Change the following properties.
org.pentaho.reporting.engine.classic.core.modules.output.pageable.pdf.Encoding=UTF-8
org.pentaho.reporting.engine.classic.core.modules.output.pageable.pdf.EmbedFont‌​s=true
Start the server.
Update : As per Rajasekaran M, he had to use the font SimHei in PRD and add simhei.ttf to fonts, inorder to work it in both PRD and BIServer.
For who have the utf-8 issue with BI server on Linux, you may need to add font for machine. Below is what I done to resolve:
copy fonts to usr/share/font/your-fonts (not work if copy to /home/your-user/.fonts)
add font command:
$ fc-cache -fv
To list all font:
$ fc-list
I have like an encoding error when the prompt is rendered.
I just installed the bullet-train theme for the oh-my-zsh plugin.
I installed the Powerline fonts as it is indicated in the bullet-train.zsh-theme file but though, my terminal doesn't seems to care.
It seems to be the right colors but there is "?" characters instead of the normal rendering.
Whereas it should be rendered like this: https://github.com/caiogondim/bullet-train-oh-my-zsh-theme
I have a MacBook Pro and I use iTerm2.
Install powerline font and pick one of those
https://github.com/powerline/fonts
For iTerm 2 users, make sure you go into your settings and set both the regular font and the non-ascii font to powerline compatible fonts or the prompt separators and special characters will not display correctly.
I finally fixed it by changing my settings for iTerm2:
simply change the font to a compatible one (powerline fonts)
I use IntelliJ IDEA to develop my Android project. I've encountered this issue when editing the string XML resource file today. The Chinese characters do show but just overlapped one by one. So basically all you see is a bunch of Chinese characters filled in and overlapped at single character space. Interestingly, when you try to delete those Chinese characters, you just delete the following XML closing tag but not the Chinese character itself...
Have tried copy/paste, same result. I am using the Windows 32bit version.
Can anybody help to fix this issue?
Please check this issue and linked issues for the problem background.
Right now when IDEA doesn't find the glyph to display in the current editor font that you have set in File | Settings | Editor | Colors & Fonts, Font, it starts to search for the first font that has this glyph and finds some font with incorrect metrics that displays overlapping glyphs.
When this request is implemented, you'll be able to specify the order of fall back fonts so that some properly working font is tried first.
At the moment the solution is to change the editor font to the one that has all the required glyphs and proper font metrics (or to find and uninstall the font that is tried first and is displayed incorrectly, note that when running under JDK 1.7 IDEA will also try .otf fonts, not just .ttf, that is why the behavior is different in IDEA 11 defaulting to JDK 1.6 and IDEA 12 that runs under JDK 1.7).