So I'm going to start using data-uri's and mhtml to embed images in my stylesheets and i'm thinking of using Jammit to help me out there because it claims that it can generate data-uri and mhtml code for you
I know about the IE7 Vista||Win7 bug and that the fix is to close off the buondaries with a two dashes
If you look at the example mhtml file provided in the jammit docs you might notice that they do not use the fix detailed above for the IE7 bug.
Does Jammit handle the IE7 bug for you? I have no way of testing IE7 so I'd just like to be sure of this before I got off and spend hours trying to get it to work
I don't think it's an IE7 bug. the Multipart MIME RFC (1341 and its successors) clearly calls for the extra "--" at the end of the last boundary. I would consider it a Jammit bug.
Update: I checked the source, and it looks like they've fixed that bug. The example was generated before the fix.
Related
Right now I'm using the latest ABC PDF version, and use the Gecko rendering engine. However, I notice that there are small differences between the way Firefox renders the HTML I'm adding to my PDF, and the way ABC PDF interprets the HTML. I was wondering if there is anything that can be done against this?
I'm asking about Firefox specifically because I thought that browser used the same Gecko rendering engine as ABCPDF did, so I thought it would be 100% the same.
Does anyone know about this? Couldn't find much about this on the internet, though I do admit that I find it hard to come up with the correct search terms.
By default ABCpdf will use the 'print' css media type whereas Firefox will be using 'screen', this can be changed by setting the media property.
var doc = new Doc()
doc.HtmlOptions.Media = MediaType.Screen
If the differences are more subtle it may be worth taking a look at engine configuration.
It is important to note the Gecko engine used in ABCpdf is independent from the engine used in any local Firefox installation, it should be assumed that it will be different in both version and configuration.
I am using Century Gothic font in my HTML and then converting it in to PDF. It works perfectly on my mac, but on my Slackware 14.1 server, when I convert the HTMl in to the PDF, the font is not rendered as smoothly as it should be.
I read several ways to include non-standard fonts in the HTML, as #font-face, or adding the entire font in the CSS file as an encoded font and both these methods worked for me in the HTML. The HTML is rendered perfectly in the browser, it's the PDF which is not getting a correct Century Gothic. Any help is highly appreciated.
Thank you
I did some research too and it seems that this is a known bug with qt-webkit.
See the issue documentation here:
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/2193
Sorry to not have better news for you. Maybe just try with a supported font that's close enough to what you like it to look?
In Safari 5.1.2 on OSX
Tech.li is completely broken.
Some people mentioned an extra div tag being the cause, but that still didn't fix the issue.
Any help would be greatly appreciated!
Pretty basic: fix your xhtml errors [Invalid] Markup Validation of tech.li - W3C Markup Validator (scroll down in the validation report to see line numbers and source code). And use Firebug with Firefox, or in Chrome or Safari or IE8, use the developer tools to find and fix the javascript errors.
I'm having troubles figuring out why Chrome and Firefox are rendering some things differently. Below are images of a part of my project as seen in Firefox (top) and Chrome (bottom). MathJax renders everything as the page is loading and once everything has been processed and typeset, it is displayed on the page. So I'm not sure if this is my fault of MathJax's fault. Anyway here are the images...
... if you would notice, the square with black border is different in Chrome, and in a bad way. Any ideas as to why this might be happening? The following is output from Chrome's console...
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Main-Regular.svg#MathJax_Main-Regular:-1
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Main-Bold.svg#MathJax_Main-Bold:-1
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Main-Italic.svg#MathJax_Main-Italic:-1
Resource interpreted as font but transferred with MIME type image/svg+xml. /MathJax/fonts/HTML-CSS/TeX/svg/MathJax_Math-Italic.svg#MathJax_Math-Italic:-1
etc...
The code for rendering the square alone, without all the other fancy stuff, is relatively simple...
<div id="square">
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
<mo id="tag0" class="expand">◻</mo>
</math>
</div>
... and then I tell MathJax to render it...
MathJax.Hub.Queue(["Typeset", MathJax.Hub, "square"]);
... and MathJax does its thing (I have no control over the rendering MathJax does). So I don't quite know where the problem is.
I know this is a very strange and very specific question but I'm hoping someone in the Stack Overflow community might have some idea or has dealt with MathJax previously. Hopefully some brainstorming will help resolve this issue.
The box you are seeing Chrome is the "missing character" symbol. The MathJax fonts don't include U+25FB, and so Chrome is showing the missing symbol. It looks like Firefox is finding the character in a different font and using that (or perhaps you have STIX fonts on the machine running Firefox but not the one running Chrome, and MathJax is using that). Browsers differ in their ability to find alternative fonts for symbols that aren't in the MathJax fonts.
In any case, try using U+25A1 instead of U+25FB and see if that works better for you.
Davide
MathML will come to Chrome natively, WebKit has been working on it for some time now:
http://www.webkit.org/projects/mathml/index.html
I guess this question should be marked as a bug for MathJax. Hopefully soon, there would be a native solution.
I do not have a real answer, however rendering differences among browsers are nothing new. I use Firefox, Chrome, Opera, IE (in that order), quite often one of the browsers renders better than the rest. Firefox has some nice debugging plugins, you may try those (Firebug???). Warning: You may spend a lot of effort on this. If you get into troubleshooting CSS, ouch :).
Did anybody successfully manage to correctly export a vcard from a Website containing Microformats (hcard) with this Firefox Plugin?
When doing so, I end up with weird characters instead of (german/spanish) Umlauts. While it's really easy to provide vcards as well, I would like to know if someone managed to correct the charset/character problems I am experiencing.
Does your document + hcard validates?