Font style ignored in eps/pdf output

[Dominik Holler]

this bug is similar to
https://bugs.launchpad.net/inkscape/+bug/166054

"font-style:italic;" of a ttf is ignored in pdf (cairo) output on windows and in version 0.45 eps output on ubuntu 7.04

[Andrey Mozzhuhin (amozzhuhin)]

Also, this bug on Linux too.
In attachment example of bug. PDF generated by command:
inkscape --without-gui --export-pdf=italic.pdf italic.svg

[jazzynico (jazzynico)]

Works well on Windows XP SP3, build 20844.
Fixed?

[jazzynico (jazzynico)]

Can't reproduce it on Ubuntu 8.10 build 20929.
Could you please confirm you're affected (or not) with new builds?

[jazzynico (jazzynico)]

Confirmed by another bug report, but probably fixed in SVN.

[jimmac (jimmac)]

The case this happens for me is when a font doesn't actually include an italics/oblique variant. Inkscape will slant the straight type for preview, but it will not render it for print or PDF export.

[Patrick Seher (jokecookie)]

this bug is still alive - ubuntu 9.10 with inkscape 0.47

[jazzynico (jazzynico)]

I really can't reproduce this bug. The comment #1 example gives a correct PDF with all Inkscape versions from 0.46 to the most recent dev snapshots, on Windows XP and Ubuntu 10.04.

I've also tried to overwrite the font-style attribute to give an oblique style to DejaVu Sans Ultra-Light, which has no oblique at all, and the exported font is a DejaVu Sans Oblique. Thus in this case, the font-style is not ignored, but the font replaced with the closest oblique one.

[mmicotti (marco-micotti)]

This bug affects also me: I have an ubuntu 10.04, just installed. Saving in pdf, it discards italics style.
I tried with Tahoma font, which have oblique/italics option, but in the pdf it doesn't appear. I noticed that now pdf is'not anymore "via cairo".. could it be this related to the bug?

[su_v (suv-lp)]

Same issue reported in Bug #586028 “Italic text doesn't work with pdf export”, reproduced in Inkscape 0.48+devel r9802 on OS X 10.5.8 with e.g. 'Arial Black', 'Impact' and 'Tahoma' (confirming <https://answers.launchpad.net/inkscape/+question/127709>): the fonts are rendered in italic on-canvas, but regular in cairo-based exports.

[cdrini (cdrini)]

I'm having the same issue, using Inkscape 0.48 on Windows XP. I was using "Lucidia Sans Unicode," and neither bold or italics were displayed correctly. It works when I check "Convert texts to paths," but that sort of defeats the purpose.

[Morgan Wahl (morganwahl)]

Can confirm this bug on Inkscape 0.48.0 r9654 under Ubuntu 10.10 using Droid Sans. (available at http://code.google.com/webfonts/family?family=Droid+Sans&subset=latin )

Even converting text to paths doesn't work.

Examples attached.

[Matthis Thorade (matthis-thorade)]

Using Inkscape 0.48 r9654 on Windows 7 I have the same problem.
The font used is CMU Sans Serif from http://cm-unicode.sourceforge.net/ which has an oblique variant.
Converting text to paths on export works as a work-around

[Matthis Thorade (matthis-thorade)]

Attached is a svg file and the corresponding pdf created using
inkscape.exe" --file="oblique_italic.svg" --export-area-drawing --export-pdf="oblique_italic.pdf"
Some fonts render ok, some don't, but I don't see yet when it happens.

Comment #5 says this happens, when a font doesn't actually include an oblique / italic variant, but how would I find out whether a font does include it or not?

[Matthis Thorade (matthis-thorade)]

and the svg file

[su_v (suv-lp)]

@Matthis - tested with Inkscape 0.48.0 (cairo 1.8.10) and 0.48+devel r10039 (cairo 1.10.2) on OS X 10.5.8, I can't reproduce your result: only 'Tahoma' fails to be rendered as oblique in the exported PDF file (see comment #9).

Fonts installed for testing: 'CMU Sans Serif' from the package 'cm-unicode-0.7.0-otf.tar.xz'
Medium: cmunss.otf
Oblique: cmunsi.otf
Bold: cmunsx.otf
BoldOblique: cmunso.otf

[Matthis Thorade (matthis-thorade)]

Hi ~suv,

thank you very much for your comment, installing cmunsi.otf solved the problem. Actually I re-installed all fonts from the cm-unicode otf package from http://cm-unicode.sf.net/ and now it works for me, so probably my first installation of these fonts had gone wrong.
I want to use the fonts, because I want to include the figures into some LaTeX document and this font is a nice and almost full Unicode re-implementation of the LaTeX Computer Modern fonts.
Maybe some time in the future I will switch to STIX fonts: http://www.stixfonts.org/
For completeness: I use Inkscape 0.48.1 r9760 on Windows 7 Enterprise 64bit.

Tahoma still fails to be rendered, as reproduced by you. Is it only because there is no 'real' oblique variant available? And do you know how I can see whether there is a 'real' oblique variant installed? In comment #9 you link to Question #127709 and to Bug #586028 (which is marked duplicate of this bug here), but I could not find a solution there.

Regards,
Matthis

[su_v (suv-lp)]

> Is it only because there is no 'real' oblique variant available?

I can't tell for sure if that's the only reason, but I can confirm it for those fonts that fail on my system to export in italic (e.g. Arial Black, Impact, Tahoma, Droid Sans) that they do not include an italics/oblique variant as separate font files (i.e. Inkscape renders the font with a "faux" style and fails to consider this special case when exporting to PDF. Possibly the available cairo functions for font/text handling contribute to the problem, but I can't really tell: I'm not a developer myself - just helping with bug triage).

> (…) how I can see whether there is a 'real' oblique variant installed?

I don't use Windows myself (on osx, I use the font manager installed with the system, which lists all available variants of a font, and can show the path to the font file for each). Additionally you can browse the directory where the installed fonts are located, and check the file properties of the installed font files.

> (…) but I could not find a solution there

AFAICT there are no known workarounds besides converting the text to path ('Path > Object to Path') before exporting (note that the status of (this) bug #200899 is still 'Confirmed', not 'Fix Committed' or 'Fix Released').

[Matthis Thorade (matthis-thorade)]

Ok, thank you for all the help

[Louis (louisgag)]

Same issue is still present with ubuntu 11.04 when trying to print italic from inkscape. Converting to path "converting the text to path ('Path > Object to Path') before exporting" works as a temporary solution, thanks!

[jazzynico (jazzynico)]

Reproduced on Windows XP, Inkscape 0.48.1, Engreavers, Sylfaen and Rockwell italic fonts.
Not reproduced with revision 10466.

Would you be willing to test the latest dev version and confirm it's also fixed with your specific fonts and OS?
Thanks!

[Matthis Thorade (matthis-thorade)]

Hi,
I downloaded inkscape_r10414-201107042125.7z and tested with the svg filed I supplied in comment #16 and can confirm that the bug is fixed for Windows 7 Enterprise 64bit german and all fonts used in that svg. This includes Tahoma.
Thank you very much!

[Michael Duelli (m-duelli)]

I can confirm this bug with lp:inkscape branch r10607 on a Gentoo system.

For me it happens with Computer Modern font (cmr10) that italics appear as regular fonts in PDF output.

[Jon (jonpad)]

Same here on 0.48.2 (r9819) on OS X 10.6.8. I raised this issue earlier as #1004149.

[Jon (jonpad)]

(See that ticket for an example file that files).

[h1repp (heinz-repp)]

Jm2c: with Inkscape 0.48.2 a document with Arial Black bold italic renders fine onscreen in Windows (XP SP3), in Linux (Ubuntu 10.04) there is no difference between bold and normal, but italic is visible. Windows prints fine, Linux on print and export to pdf looses italic (and bold, but that lacks onscreen also).

This bug is around for 4 years, it affects more Linux than Windows users, is pretty visible and breaks user experience at an unexpected point: when a project is finally ready, everything looks fine on screen, but the printed product is broken, and there is no way to make it work except have the file printed from a Windows box (if it works there). That said the severity of this bug seems somewhat underestimated.

[Jon (jonpad)]

@h1repp - one fix I've found is to look in the <tspan> element and remove the "-inkscape-font-specification" attribute. So long as the font-family of the parent tag is the non-italic version of the same, it will render fine. So if you can get something in your workflow to modify this (PHP/Ruby/whatever script, XSLT processor etc.) then you may be able to can plug the gap (works on OS X 10.6.8 manually, as per my dup ticket).

[h1repp (heinz-repp)]

Jon: thank you for your hint, didn't spot it until now.

Just returned to post the workaround I found: on Linux/Ubuntu on the "Render"-tab (or similar, in German it is called "Rendern") of the print dialog there is a radio button "Bitmap" vs. "Vector", the latter preselected. Selecting "Bitmap" and a resolution that fits the printer (say 300 dpi) gives a printout that matches the screen, and renders also Arial Black bold italic the way it should.

[David Mathog (mathog)]

Possibly a related bug. rotE.svg uses only Arial bold font, when written to rotE.pdf via the Cairo driver that becomes Arial Bold Italic.

[David Mathog (mathog)]

Conversion using Inkscape r11664 on Windows XP.

[David Mathog (mathog)]

Hmm, rotE.svg is actually very strange.

When open in Inkscape it shows Arial,32,Normal, but the SVG shows some Agency FB lines. The <text> is Agency and the sole
<tspan> it contains is Arial.

Made rotEc.svg where there are E1 (red) and E2 (blue) manifestly not in the same font yet both display as Arial,32,Normal.

So this may be some other issue involving improper display of font information. It does this all the way back to 0.48.2 windows. r11679 linux also shows both the red and black E as Arial 32.

[David Mathog (mathog)]

Screen shots for r11679 (linux0 with text selected from each of two strings in rotEc, notice that both say "Arial,32, Normal", yet the fonts are not the same.

[David Mathog (mathog)]

The problem is that the font-weight is not propagating properly into the display. In rotEc.svg for "E1"the font-weight=bold from <text> is not being overridden by anything in the <tspan>, so the characters are bold, for "E2" there is a font-weight=normal in the <tspan> so the characters are normal weight. However, in both instances the font information at the top of the display shows "normal". The text and font tool has the same issue.

[David Mathog (mathog)]

Sorry about the posts about what turned out to be an off topic issue. Moved to Bug #1061128

[MOW (wolter)]

Still present in r12248 ... in a way.
I have a document with only 1 font, Arial Rounded MT Bold.
If I set a part of the text to italic, inkscape renders on the screen just fine, but export to pdf does not work, not even als path.
If exported as text, the font gets embedded twice, which does not really help with looking different.

Having just upgraded from r11870 to r12248, the same problem occurs on existing SVGs.
However, now I don't even get the option to select another font style than Normal.
While this will prevent the problem from being created with the current version, it will still happily display WYSINWYG for styles set with older versions without warning.