www.cloudformatter.com

cloudformatter format requests: 1,209,071    pages delivered: 3,116,271

@cloudformatter FAQs

xportability LLC

@cloudformatter FAQs

http://www.cloudformatter.com

I am trying to format my <svg> and nothing shows up.
While we are not looking at your content unless you send to us, we can make an educated guess that will be right 99% of the time. The code you are using to generate SVGs is not adding the appropriate namespace for SVGs or you do not have the appropriate namespace on any SVG you are inserting. You need to add the SVG namespace:
<svg xmlns="http://www.w3.org/2000/svg">
  <!-- more tags here -->
</svg>
This should be on your SVGs either if they are dynamically generated or inserted by hand in your page. Otherwise, well, they are wrong. Don't fight with us, edit the library you use to do it right. Many SVG libraries do not do this and they are wrong for doing it this way. In our example pages we provide many samples with properly implemented code that inserts the proper namepsace on the generated SVGs. Just do it. It is right to fix the issue at its source. We should not have to guess whether a tag in your document is really an <svg> or not when you do not specifically set that contents namespace.
I am using ::before pseudo element to display special characters in my CSS, but they are not in the print out. What gives?
Psudo elements like ::before and ::after allow you to insert content onto a page from CSS (without it needing to be in the HTML). While the end result is in the browser page, is is not actually in the HTML DOM. Thus you can't select and manipulate them directly with jQuery (or any JavaScript APIs for that matter, not even the Selectors API). If you export the DOM as the Javascript plugin does, they are missing. We have a solution in process that supports some of these. Currently font library ones like Gylphicon Halflings and Fon Awesome icons work. We will release complete support for pseudo elements :before and :after soon.
I get an error that your "http" service cannot be called from my "https" website, what can I do?
You are using the default http links to the formatting engines but are hosting/calling the Javascript from a secure https website. The formatting servers have both regular and secure links. You can change the Javascript to access the secure servers by changing these:
  • xep_chandra_service: 'https://xep.cloudformatter.com/Chandra.svc/genpackage'
  • xep_chandra_service_AS_PDF: 'https://xep.cloudformatter.com/Chandra.svc/genfile'
  • xep_chandra_service_page_images: 'https://xep.cloudformatter.com/Chandra.svc/genpageimages'
None of my images are appearing, I only get a red "x". I am running a test site locally. How do I fix this?
When you run locally, the Javascript is building URLs to included images to send to the remote server to format. Hence, your image URLs are probably something like "http://localhost:8080/images/myimage.png". Of course, when this is received at the remote server, that image is not on the formatting box. If you want to test locally, you can either:
  • Use base64 encoded images and insert them right into your pages. This would transfer the base64 encoded image to the backend for processing. This is now possible automatically for <img> tags only using embedLocalImages option to the formatter set to 'true'.
  • Put the images someone on the web that is accessible and use an absolute reference to those images.
I get an error like The exception message is 'The 'xxxx' start tag on line ### position ### does not match the end tag of 'yyyy'.
The Javascript code does it's best to compensate for the differences the HTML community has imparted by creating areas where end tags are not necessary. The whole processing system is based on XML, so we have made a best effort attempt to close all empty tags. However, new rules in HTML have started to appear when exporting the HTML DOM and converting to XML. For example, a <ul> that is the first content inside a <p> will cause some browsers to omit the </p> tag because the HTML standard allows this. If you get one, please send us the details. We are trying to catch them all or possibly implement an alternative to XMLize the HTML that is foolproof. We have found nothing yet that is acceptable.
Is this really free?
It is "free" in the sense that you are "free" to use it. There are no warranties, guarnantees, uptimes or anything promised. If you want those things, we have commercial offerings you can ask us about. It should also be noted that you are "free" to not abuse the service. We only monitor site volumes and where requests come from. If large abuses occur in formatting that impact other "free-to-use" folks, we will be "free" to block the site or propose one of the commercial offerings.