I'm facing an ennoying problem.
When I create a PDF from HTML, using the CSS property "letter-spacing" on some divs, browser (Firefox) and PDF (Gecko) renderings are different.
Actually, it appears that ABCPdf is adding somehow a constant to my value.
For example, if I declare a 1.1px letter-spacing, ABCPdf renders a 0.8px. This "constant" depends on the font-size (here 12px).
I'm using a monospace font : Courier New, Courier, monospace
What should I check ? I'm already using FontEmbed = true, in order to have a better quality.
I can't ugrapde my version of ABCPdf.
Thanks for reading :)
I think you are better off using a style for print media like #media print {} to adjust font spacing accordingly.
ABCPdf is using Gecko 21 which is quite a bit behind current Firefox. That's probably what is causing the difference.
Related
We're having some trouble displaying the latin small letter a with caron (ǎ or U+01CE) correctly in Windows 10 - Chrome with font-family Verana. It displays the caron next to the letter 'a'. Other fonts display it correctly.
It works fine in Firefox and IE (under Windows/Linux/macOS) with Verdana.
Also Chrome in Linux/macOS displays it perfectly. The combination Windows + Chrome + Verdana seems to be the only one having difficulty.
For example, check Graphemica a with caron and put the font-family of the example letter on
font-family: Verdana
If you have Windows it will display the caron not above, but next to the letter 'a'.
Does anybody have an idea how we can fix this for Windows Chrome users?
Other letters with a caron, for example: č (U+010D) works fine.
Does anybody have a suggestion how we can let this 'ǎ' work in Chrome - Windows - Verdana, without changing the font?
Thanks in advance.
It doesn't display correctly because U+01CE is not present in Verdana. The components (a, caron) are both present, but there is no character (nor any OpenType layout rules) that combine them into U+01CE form. When you see it "working" in other browsers, it's likely because it's substituting with a fallback font whose design is similar to Verdana (or it's at a small text size where you can't see the difference).
More about Verdana here: https://learn.microsoft.com/en-us/typography/font-list/verdana, have a look at the "Code pages" section. None of the listed pages contains U+01CE, so the font simply doesn't support that character. The other characters you mention are in Verdana.
To work around, you could use some simple CSS to set up a fallback for that specific unicode, for example something like this:
#font-face {
font-family: "fallbackfont";
src: local('Tahoma');
unicode-range: U+0100-01FF;
}
<p style='font-family: fallbackfont, Verdana; font-size:72px'>a ǎ</p>
NOTE: I chose local 'Tahoma' for a fallback here because its design is more similar to Verdana than others. And it is selected for use for the entire Unicode range of U+0100-01FF. But you could (probably should) use a webfont or other local/"web-safe" font of your choosing. Also, you could set the unicode-range for just the one character if you're sure that's the only one not displaying correctly for your text.
I am using scripts to fill Indesign document with text. There is standard unicode characters (emoji, cyrillic, maths, arabic) but sometimes they are are not in one font. I have to take it from different fonts.
Is there a solution like in browser CSS where i specify few fonts ordered by priority font-family: font1, font2, font3?
Definitively nothing like CSS font-styles enumeration but thanks to InDiScripts "IndyFont" a/o FontMixer from same Author to generate either a fully customized font or a composite font:
FontMixer : http://www.indiscripts.com/post/2013/07/fontmixer-extend-typefaces-in-indesign
InDyFont : http://www.indiscripts.com/category/projects/IndyFont
I have such problem: in all browsers font is what I want - "Helvetica Neue", but Firefox use second font in font-family list.
I checked it in Firebug:
/rule from Bootstrap.scss/
p → "Helvetica Neue",Helvetica,Arial,sans-serif
parent matched//
Here is screenshot of what I have in Firefox:
And in Chrome:
or my font is not valid for Firefox ?
The whole reason for font-family list of font types is that if the client machine/browser doesn't have the first font on the list available, it will use the second, and if the second is not available it will use the third.
EDIT:
If you really must use the font family you want, you will need to get the font file for it and load it. here is a link to the thread that discusses this:
How do I load external fonts into an HTML document?
I know this is perhaps an open-ended question, but I'm hoping some #font-face expert could give me some insight into a best-practice.
At this point in time, is it acceptable to use an #font-face embedded font for body text? I'm arguing with a designer and thinking no, because a FOUT could result in a big change in the layout of the content if a font takes a moment or two to download.
The question is - should I be concerned about the possibility of fonts taking a few moments to download and potentially causing a big shift in the rendering of the body?
Quite late, but here's my opinion: Your main concern with using font-face for body is not the loading time, but the rendering. There are only a (very) limited number of fonts that render well in all browsers and ios. Now, as long as the text is readable (small sans serif with good space between lines) and renders well, there is no real difference from a performance point of view (the font will only be downloaded once, and you can load it before you load your content to avoid any shifting).
I have Museo-300 mostly working with #font-face, but certain letter combinations like "ff" and "fi" are disappearing in Firefox (confirmed in v3.6 and v7.0.1). So "microfinance" becomes "micronance".
Note that I'm outputting these as individual letters, not as ligatures. When I view source on both the server and the browser, "coffee" for example is spelled with all six letters individually—not a unicode ligature character for "ff".
The output looks right in Opera, Chrome, Safari, and IE (even IE6).
I downloaded Museo-300 from MyFonts along with their web font example template.
#font-face {
font-family: 'Museo-300';
src: url('webfonts/151B6C_0.eot');
src: url('webfonts/151B6C_0.eot?#iefix') format('embedded-opentype'),url('webfonts/151B6C_0.woff') format('woff'),url('webfonts/151B6C_0.ttf') format('truetype'),url('webfonts/151B6C_0.svg#wf') format('svg');
}
and all the referenced files are in place. I invoke it like this:
font-family: 'Museo-300', sans-serif;
I tried a different font as a test (Code Pro Light Demo, also gotten from MyFonts) and Firefox dropps "fi" but not "ff" for that one.
An idea what's going wrong?
For anyone reading this in the future, note that as of FF 15 (I think) the syntax has now changed, and you'll need to use this:
-moz-font-feature-settings: "liga=0";
-moz-font-feature-settings: "liga" 0;
You can tell Firefox to skip looking for ligatures and treat them as regular characters by adding
-moz-font-feature-settings: "liga=0" in your font-face declaration.
In case others hit this problem, I resolved it with help from MyFonts technical support. I'm not sure whether this issues is specific to MyFonts, but I suspect it affects other web font sources.
Direct (Solvable) Cause
When a standard True Type font (TTF) gets processed into the multiple versions that are useful for a web font (EOT, SVG, WOFF), the processing tool or vendor can decide whether or not to include the font's full character set. Some will default to a reduced character set to reduce file sizes.
In my case, one or more of the generated web font files excluded ligatures, presumably considering them to be non-essential typographic tweaks. To fix the problem I used a custom web font builder at MyFonts to generate font files with the full character set.
(For MyFonts specifically this was at Order History > select relevant font > Webfont Kit Builder tab > Advanced, then check both "Complete Character Set" and "Keep OpenType Layout".)
Underlying Cause
My belief, which is only an educated guess:
I think Firefox is going out of its way to do nice typography, more so than other browsers. So when it sees something that it could render as a ligature ("fi", "fl", "ff", etc.) it tries to render the letters as a single ligature glyph rather than as two distinct characters. If your web font doesn't include the ligature glyphs, your letters will disappear. (If my guess is right, I'm surprised I haven't read about this problem before.)
Myfonts.com recently changed some display settings. Their support wrote back very quickly with the following info:
If you click on the Font image (the image that shows the sample),
which is located right above Kit Options, you will see the Complete
Character set and Keep OpenType Layout options.
This view is not currently available through Firefox though, but I was able to download the complete character sets using IE9.