Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I've spent eons diving into @font-face issues for RTL languages, font-rendering on different browsers, PDF support, and so on.

My objective is to have CSS-compatible Arabic (a RTL language) text on an HTML document, which , when rendered into a PDF, looks, renders, and wraps exactly the same on the PDF as it did on the HTML webpage, regardless of the user's browser or platform.

I've been using @font-face but it turned out that Windows machines render fonts a little wider than they do on a Mac, while the PDF generator is browser-independent and seems to render fonts more like a Mac does. So what happens is that Windows users see one line of text, while the PDF ends up having the last word on that line wrapped over onto the next line, and so the PDF is not exactly what the Windows user expected it to be.

I thought at one point that Cufon could be the solution because apparently it looks the same cross-browser - but I think it doesn't support Arabic? I tried generation PDFs using wkhtmltodpf and PhantomJS, but despite being awesome 'virtual' browsers, both use Webkit QT, which renders text differently from Windows, so once again the PDF that was generated had line wraps or text width that wasn't the same as the way the original HTML document looked on a windows browser. Basically, my question is:

  1. What's the best way to ensure that whatever the user sees on their browser is exactly what they see on the PDF? Does it all come down to using images?
  2. On an aside, does HTML5 have some sort of cross-browser font-rendering?
share|improve this question
4  
I think you start with false premises. HTML is a markup language not a layout language. Even when used with CSS you will never be able to yield the same visible output on all platforms. That's not what it was designed for in the first place. If you really require visual equality on each platform the best way is to provide a PDF instead of HTML (even with PDF you will experience minor differences between individual PDF readers). Better is to relax your requirements. –  Marco Feb 11 '13 at 14:55
2  
The short answer is that you won't find any truly cross-browser/cross-platform font-rendering. –  JohnGB Feb 11 '13 at 15:37
    
Meaning - in order to ensure I serve a PDF that looks exactly like the HTML design that users made via a WYSISWYG editor - then the only thing I must do is resort to images substituting text? –  user961627 Feb 11 '13 at 15:44
    
HTML does not “look like anything”. It simply states that this element is a headline and that element is a paragraph and the next thing is a list, etc. How all this is actually rendered is a different matter. –  Marco Feb 11 '13 at 16:13
1  
I edited your question title to reflect the actual issue (CSS font embedding). And the answer is: no, there is no reliable cross-browser/cross-platform way to render embedded fonts--let alone render pixel-perfect matches of the page in general. –  DA01 Feb 11 '13 at 16:27
show 2 more comments

closed as off topic by Matt Obee, Mervin Johnsingh, kontur, ChrisF, Kit Grose Feb 12 '13 at 3:21

Questions on User Experience Stack Exchange are expected to relate to user experience within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

up vote 3 down vote accepted

The problem is that you are starting with an incorrect assumption: That the same HTML and CSS will look exactly the same in any browser on any platform with any user settings.

That's just not how the web works. Every browser has it's own rendering engine, it's own quirks, it's own operating system and user preferences, it's own browser size, etc.

Add to that the wildly varying ways that embedded fonts via CSS render and the simple fact is that you just can't do what you are attempting to do.

You could render the entire page as one image. That will give you full control. Granted, you lose all text and therefore make the PDF rather useless in terms of indexing and searching and accessibility, though.

share|improve this answer
    
I've tried this. The application needs to go from HTML elements added onto the page by the user to create a design via a WYSIWYG editor - from that HTML-created design to PDF. To render it into an image also requires an HTML-parser - & the only way this is done as far as I know is using HTML-to-image applications which are based on QT-Webkit. So even in rendering the whole page to an image (screen saving), I still need to rely on HTML rendering that sometimes wraps text in places it wasn't wrapped originally. That's why the only solution I can think of is one that ensures the text stays put. –  user961627 Feb 11 '13 at 16:42
    
I know that the same HTML and CSS won't look the same in every browser. I'm just trying to find a way to at least create that effect with respect to fonts rendering, at least the width of the string, to prevent unexpected line wraps. –  user961627 Feb 11 '13 at 17:21
    
@user961627 unfortunately, you just can't. That's the nature of the beast. –  DA01 Feb 11 '13 at 17:23
    
I guess so... But how on earth is this site rendering its fonts then? vistaprint.com It's certainly not Flash... please check out Business Cards > Premium Business cards, and then customize a card with your own text, and notice their canvas. It's all javascript and text as far as I can tell, yet the fonts don't render the way other fonts do on my Windows-based browser. I zoomed in on a text element code using Firebug but I can't find the string that I typed in there, neither does there seem to be any image. Any ideas what on earth they might be doing? –  user961627 Feb 11 '13 at 17:28
2  
It appears they're rendering an image on the back end. That gives them the advantage that they have control of the rendering system being used, as it's on their own servers, so they can ensure that what you see is what you print. In other words they are not relying on the end-user's browser. –  DA01 Feb 11 '13 at 18:02
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.