I need to collect data from a visitor in an HTML form and then have them print a document with the appropriate fields pre-populated. They'll need to have a couple of signatures on the document, so it has to be printed.
The paper form already exists, so one idea was to scan it in, with nothing filled out, as an image. I would then have the HTML form data print out using CSS for positioning and using the blank scanned form as a background image.
A better option, I would think, would be to automatically generate the PDF with this data, but I'm not sure how to accomplish either.
Suggestions and ideas would be greatly appreciated! =)
I would have to respectfully disagree with Osvaldo. Using CSS to align on a printed document would take ages to do efficiently in the aspect of cross-browser integration. Plus, if Microsoft comes out with a new browser, you're going to have to constantly update for the new use in browsers.
If you know any PHP (Which, if you know JavaScript and HTML, basic PHP is very simple), here's a good library you can use, FDPF:
Thankfully, PHP doesn't deprecate a whole lot of methods and the total code is less than 10 lines if you have to go in and change things around.
You can control printed documents acceptably well with CSS, so I would suggest you to try that option first. Because it's easier.
This is actually a great php library for converting HTML to PDF documents http://code.google.com/p/dompdf/ there are many demo's available on the site
XSL-FO is what I would recommend. XSL-FO (along with XSLT and XPath) is a sub-standard of XSL that was designed to be an abstract representation of a formatted document (that contains, text, graphic elements, fonts, styles, etc).
XSL-FO documents are valid xml documents, and there exist tools and apis that allow you to convert an XSL-FO documet to MS Word, PDF, RTF, etc. Depending on the technology you use, a quick google search will tell you what is available.
Here are a few links to help you get started with XSL-FO:
http://en.wikipedia.org/wiki/XSL_Formatting_Objects
http://www.w3schools.com/xslfo/xslfo_intro.asp
http://www.w3.org/TR/xsl11/
Related
Suppose you're developing a web site and blind users will be a significant chunk of your target market. If the web site includes document editing functionality, what would be appropriate WYSIWYM tools? Are languages like Markdown, Textile and Wiki Formatting really accessible or are they inconvenient to blind users?
I'm a blind programmer and while I haven't used most of the languages you mention I've found that any markdown language is fairly easy to use if you have the desire to learn it. I've had no problem using either HTML or several markup languages for wiki's. Part of it will depend on how invested the users are in your site. If it's a site that will be visited infrequently or for short periods of time, it's much less likely that a user will take the time to learn the required markup whether they are blind or not. Unfortunately, I have not found an accessible JavaScript WYSIWYG editor but I find it easier to manually enter the markup so haven't looked very hard.
the first question is: how important is semantic structure? could you get away with plain text. You could do simple parsing like treating blank lines as paragraph markers, treating a series of lines which begin with * as a bulleted list, identify URLs and make them into links, etc.
As a blind developer myself, I have no problem in understanding languages like Markdown. But if it's a syntax I'm unfamiliar with, I'll only learn it if I expect to use the site very often, or care deeply about the content.
Two final thoughts come to mind: while I certainly experience some accessibility challenges using TinyMCE, you could develop something much simpler - provide less than 10 formatting options, like inserting hyperlinks, making lists, centering text, setting the style (such as heading) etc.
And lastly, when I talk to non-technical blind people, they often just write their content in Word and paste into a wiki or blog post. This sounded strange when I first heard it, but it does make sense. So an ideal solution would accept pasted in content.
In closing - it depends how important this is, and how much effort you want to expend. Maybe a Markdown editor with a live preview (like on this site), buttons for inserting simple formatting like URLs, and the ability to paste in rich text would tick all boxes :-)
On a web page, the most accessible embedded text editor for blind users is one that uses standard HTML, such as a <textarea> element, with a corresponding <label> element:
<label for="editor">Enter your text here using wiki markup:</label>
<textarea id="editor"></textarea>
If a WYSIWYM tool is built using standard accessible HTML, then blind users can easily enter text into it, with full confidence that they're entering text in the right place. Then the question becomes: Which is the better markup language? They all require memorization, but some may be more intuitive than others. One way to find out which is best would be to do some usability testing with a wide variety of target users. Also be sure to providing easy, accessible access to syntax help.
Picture yourself working in pure text 80x4 display (just open a console and resize appropriately), then use vi/emacs/ed and you'll soon realize what markup will get in the way.
Try to do as much work as possible to understand plain text, else use light markup like POD, finally things like AsciiDoc are very powerful but needs training.
I don't know about WYSIWYG/WYSIWYM tools, but I do know that complying with W3C standards (especially their HTML5 en CSS3 drafts) while writing your own editor code will help a lot.
In CSS you can specify speed and intonation of speech. In HTML you can specify alternative text (alt attribute in many elements) that screen readers are compatible with. Be sure to know when to use the abbr and the acronym elements. Use the former when you want the screen reader to read the meaning of an abbreviation and the latter when the acronym should be read as a word (e.g. ASAP, NATO and OS).
For the editor itself, I recommend creating a WYSIWYG editor that uses divs and spans. Screen readers will understand easily the structure of a document. For the current line, use a text box; for every other line that's not being edited, convert the contents immediately to valid HTML.
If you find a good tool, be sure to post it here. I'm looking for one too. :-)
I've been having a heckuva time with this problem, and there seems to be a lot of noise out there in search engines in getting to the bottom of it, so forgive me if I've missed a silver bullet out there.
The base need is that I have to generate a PDF document that has both static and dynamic elements. I started to do this by having a PDF template with all the static content, and then I wanted to inject various dynamic elements into it. The problem is that PDFs are not meant to be manipulated that way, and depending on the size of the dynamic text I put in there, might overflow text on other pages. I was using iTextSharp but can't get past this problem.
A possible fallback is to generate a DOCX, which I've done before, and then convert it into a PDF on the backend. The only libraries I've found to do this are paid apps (like Aspose). There are examples out there that convert to PDF without these libraries, but they seem to require a client-side application. I'm doing this via IIS.
To make a long story longer...are there free libraries that will convert a DOCX file to a PDF server-side without launching client applications to do so?
There are a few choices here:
build a COM interop class that will perform read and 'Save As' functions on your .docx. The MSDN link you gave doesn't require to be run client-side, but rather have the Office assemblies in the GAC or in your ASP.NET's bin directory.
buy a third party component to do the work for you. Here's just one example with no guarantees.
I'm not familiar with any good free ones, but we used Aspose.Words to achieve something similar to what you describe. We keep Word templates with static text and mail-merge fields. The templates can be regular Word documents, they don't have to be .dot templates. Mail-merge fields can be either single fields or repeatable data in tables so you can easily generate pretty complex documents without doing dynamic document editing. (Which is always an option)
Using Aspose for this was so friction free that I would suggest using Aspose unless the cost (which is significant) is a show-stopper. The support is also good which is always an added bonus.
There are always some caveats...
I would have liked more control over the PDF compatability of the generated PDFs. We had some issues with older clients reading the generated PDFs.
Mail-merge is not fun. Complex mail-merge expressions was time consuming to get right.
I just found very simple solution to convert any files from command-line using LibreOffice:
soffice.exe --headless --convert-to pdf file.xls
(google for the rest)
Simple situation. I'm trying to write my own blog with a minor twist. Part of the blog will be controlled from a client application instead of a web interface. Basically, I'm still in the design phase and haven't written a single line of code. But I'm trying to combine several techniques into an interesting exercise in software development. Thus I want a client application which I can use to write articles in, which can then upload the article through a web service to the server. (The client would be Delphi 2007/WIN32 and the service is ASP.NET/C# with SQL Server.)
The article itself would be stored in RTF format, including images. This would be in a local database on the client, which would also keep track of the article's status. Once uploaded, it will keep the article synchronised with the version on the server. Technical details are just boring and as said before, still in a design phase...
But I do need a good solution to convert the article from RTF in the database to HTML to be displayed in the blog. I have two options:
Upload both the RTF and HTML from the client, with the client doing the convertion from RTF to HTML.
Upload just the RTF and let it convert on demand on the server. (Or convert on the server when the RTF is uploaded.)
Option 1 would need a Delphi/WIN32 solution to convert it while option 2 would need a .NET solution for the conversion. I don't want an RTF editor for .NET but need a good option to use in Delphi 2007. And I need something to convert an RTF to HTML, which would keep (almost) all formatting and which would include all images from the text. This could be both in .NET or Delphi.
So, I have the following questions:
Is there a good, free RTF editor for Delphi which can handle images?
Is there a good RTF-to-HTML converter for Delphi or C# which can keep as much of it's formatting intact as possible, including images?
Some good suggestions for .Net:
Convert Rtf to HTML
Since you provided so much background about why you are doing it, I am going to provide some feedback on the whole plan. This may not be an answer to your question directly though. Sorry.
You might consider looking at Windows Liver Writer for the client. If you just implement an API it supports then it can do all the editing.
Also, I would suggest skipping RTF all together. Converting from RTF to HTML will loose some formatting, and typically create sub-optimal HTML. Creating an RTF with the sole intent of converting to HTML is a less than optimal solution.
Instead keep it HTML for the round trip. If you must use RTF, then limit the RTF formatting to the HTML formatting you want to support. That way the conversion will be more accurate. Then convert as soon as possible, providing a preview for the poster. Since it won't always convert accurately you want the poster to see any of the conversion oddities before they make them public. That way they can fix them before they are embarrassed.
You'd better take a look at TRichEditWB component in EmbeddedWeb component pack. The whole pack is open-source:
http://www.bsalsa.com/forum/forumdisplay.php?f=29
You can add image, and even controls like buttons and checkboxes to TRichEditWB. It also can hilight HTML and XML code, and recognize URLs automatically.
We have a requirement to export different pages of our I.E. only web application to Excel/pdf documents.
The pages have graphics/grids/text, etc...They should also be printable as well.
I heard weSuperGoo mentioned, but have no experience with it.
I am in the research phase now and I wonder what tools/technologies/methods are out there for this task?
I would appreciate any pointers/direction.
Thanks!
We have used ABCpdf by WebSupergoo which includes the ability to retrieve a URL and convert it to a PDF (see documentation). This means all we need to do is provide a suitably formatted version of the page in plain old HTML and point ABCpdf at this URL and it will convert everything automatically for us - beats having to build the page up manually element by element.
I should add that this isn't perfect - we have had some issues relating to matters like paging (very difficult to page HTML when you need things like headers and footers on every page) but for simple uses it's up to the job.
You can get ABCpdf free if you're prepared to link to them.
To export to Excel, you can simply just export a HTML table as HTML and name the file whatever.xls. Excel will automatically convert the HTML table to a spreadsheet. I've been using that trick for many, many years. If you're using something like a DataGrid, then that makes it even easier to just write out the contents of the control to a HTML file (or string) and then return it as a .xls file.
For PDF, I recommend iTextSharp. It's really easy to use and has worked well for me for many years. You can use the iText (Java version) documentation or the iTextSharp documentation, the methods and classes are the same (maybe capitalization is different, but you should be able to figure it out.)
Links
http://itextsharp.sourceforge.net/
Does anyone think it is possible to build a Google Docs style PDF document viewer, which will convert a document to a format that doesn't require Adobe Reader on the client machine?
If so, any references to point to? Either a place that had done it, or an explanation of how to do it.
I've done a lot of research regarding this matter and I hope I can help.
Good old Macromedia used to market Flash Paper, which was supposed to be a PDF Adobe Reader killer as it allowed any webmaster to embed and display PDF docs online using Flash. But that was before they sold out to Adobe and Flash Paper was soon put on a shelf and forgotten in favor of Adobe's priorities.
However, Today there are a so many ground-breaking alternatives...
As a user has mentioned above you can use Scribd.com (the wanna-be YouTube for documents). But they're not the only service (and certainly not the ones most ahead of the curve).
Here are my two favorites:
Issuu (http://www.issuu.com)
Mygazines (http://www.mygazines.com/)
I enjoy Mygazines's flash user interface the most (it's also faster) but it costs $99. It's pretty impressive. Depending on what you want to do that price tag can be worth it.
Issuu however, has won me over recently with their Smartlook Platform: http://issuu.com/smartlook
Here's a sample of Smartlook setup on a website:
http://www.ismartlook.com/
Plus it's completely free, which is nice.
A third alternative, which I've considered using myself is this free and open source code made by this guy named samurajdata. He calls it psview (PostScript Viewer). Anyone can download the source code and see it in action here:
http://view.samurajdata.se/
The converted PDFs losses quality as it converts to image fie, but it's fast and easy to setup.
I hope this helps!
You may try Doconut.com looks pretty same as Google Docs viewer. It is available for asp.net 4.0, apart from PDF it can also show all office formats, tiff, dwg, psd etc.. However it is a paid library.
If I understand you correctly you only want to view these files and not edit them.
Google already makes a best effort at providing PDF files found in it's search results as HTML. This doesn't always work. You can try it out by setting up a gmail account, mailing all your PDF files to it, and then using all the "View attachment as HTML" links in the messages.
Your other options are to take the source material and make it into HTML as say LaTeX2HTML does for LaTeX documents, or to convert the PDF into one of: a raster image (tiff, DjVu, etc), or a vector image (PostScript, SVG, SWF).
If the input to this process starts with the PDF files, you have very limited options, especially if the contents of the PDFs are just raster images (say scanned pages).
Personally I'd advocate for creating the PDFs from their source and trying to use Flash Paper to create an SWF out of them too as Flash Paper will pretend to be a printer. Because some 98% of browsers have Flash 9 or greater.
Have you seen Scribd?
You can just use the Google Docs Viewer which also supports PDF documents. It allows you to embed it in your web page and point to the URL where the PDF is located (which doesn't have to be on the Google servers).
Example:
http://docs.google.com/viewer?embedded=true&url=http%3A%2F%2Fwww.domain.com%2Fdocument.pdf
There is the Internet Archive BookReader available. It's a nice book viewer implemented in javascript (jQuery), so the client doesn't need a PDF reader nor Flash. Though it needs images for the book pages, you can easily connect it to your own image server, so you may try to convert a PDF to images via ASP.NET (or any other tool like XPDF). I found that this is simpler to implement than actually implementing an images viewer.
Also, it seems to support search highlighting (try it here), but I haven't investigated exactly which metadata are needed and in what format.
The last release file contains a simple example on how to use it. More details and examples can be found in the first link.
Try converting them from PDF to TIFF. Tiff supports multiple pages and is widely supported.
If formatting isn't that important, and your PDFs are structured right (ie actually contain text, not images of text), an alternate could be to convert to HTML. The tools from Aspose are pretty good.
I'm wondering why you would want to do that. PDF is such a general and widely supported format that if you try to avoid it you're limited to:
A more obscure or less well supported format (dvi, svg until it gets better support)
Converting to text/HTML like Google does with less than perfect results
Converting to an image format like TIFF which bumps up file sizes and removes all the niceties of PDF like real, selectable text and hyperlinks
If you don't want your users to have to install Adobe Reader (understandable), there are many free lightweight PDF viewers available (Foxit Reader for example), I'm sure many of these have browser embedding capabilities.
Am I missing something here? Google Docs DOES support PDF. Simply upload the PDF file.
Some other alternatives depending upon what you're looking to do:
RAD PDF - ASP.NET component for displaying PDF documents, forms, etc. Also allows PDF searching, bookmarks, text selection, and basic editing.
Atalasoft - ASP.NET component for image viewing, but also allows PDF use as an image. Doesn't support any PDF features beyond simple viewing.