We are in a need to interact with a Document Management Systems which saves file (mostly PDF & DOC & DOCX) as an array of bytes and saves also its file extension.
So, we need to build a file viewer which display files in client's browser.
We think of converting DOC files into PDF and preview converted file in browser, others think of converting array of bytes to HTML (this solution is a big question for us as we don't know how to do this and if this is available or not) and transfer rendered html.
But we don't think that these solutions are the best and cross browser solutions.
So, is there any way to do such functionality? which must be a cross browser solution?
The first question you have to answer is whether the users need to be able to edit the documents. If so, then your best "viewer" is going to be a the Word and Adobe client apps. Please note that in this case, you will also need to give the users the ability to upload (and possibly check-in) the edited documents.
If the users just need read access, then you can certainly just show them an image or PDF of the file in their browser. If you go the PDF route, you will save money using Adobe reader, but it will be a "clunkier" user experience.
If you want to give your users a read-only view, you will need to "render" .doc files into PDF's or TIFF's or PNG's or whatever. I don't recommend doing this in the browser unless ALL of your documents are VERY simple.
If you users require a single, web-based interface for all of their rendered .doc and .pdf files, then you may want to consider using an java or activex-based document viewing applet. Daeja is the most popular vendor for this type of viewer, and it even gives your users the ability to annotate documents.
One more note. Rendering .doc files can be a very expensive, cumbersome, and error-prone process. I've worked on numerous systems at multiple companies that have tried this, and no matter what we did or how much we spent, it never worked terribly well.
Good luck!
Tom Purl
Related
I want to provide some very simple content to the user that describes how to use a web form.
This text could just as easily be written in HTML, however, convention among the content writers is to write all help text in Word, convert it to PDF, and then put a link to the PDF at the top of the web application.
Assuming that the PDFs are tagged and/or 508 compliant, does this practice present any accessibility concerns?
There are two issues posed with your question:
(1) PDF when it could be HTML
This requires the user to have software that reads PDF format.
This requires the PDF to be tagged and made accessible.
This interferes with usability and is problematic for some users, especially on mobile where the focus switch to a different (PDF reader) application looses focus on your web page or web browser.
(2) "breaking" accessibility
The accessibility of your web content is evaluated on its own merits: you certainly can have an accessible PDF but if your reasoning is your HTML does not need to be accessible because of that, you are not accessible and fail your end-users.
There is also a hidden use-case for accessibility or usability you might not consider: web crawlers and indexing. Users rely on web searching to find content and your PDF is not indexed to map to your web page content in most search engines, so users will not find the help they need.
Most reasonable people involved with Section 508 would likely agree it is not accessible, as it fails 1194.22(n): When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
ยง1194.22 Web-based intranet and internet information and applications
It is possible to convert Word content to HTML, and you are always highly encouraged to write the content as web content, because there are sometimes issues we simply accessing, and opening PDFs depending on the device they are using.
But to answer your question: no, as long as your PDF is accessible. I'd suggest putting it through something like the accessibility audit tool if you have Adobe Acrobat. If you don't, you might give content creators a simple check list, such as:
does your image have alt text if needed? (consider a decision tree/flowchart, example)
are your headings marked properly using the built-in styles?
are your tables formatted correctly? also tables are not used for layout
You'll probably notice these are typical guidelines when writing web content, but also apply to documents (Word, pdf, etc.).
WCAG has a list of PDF Techniques that you also want to check, but generally if you make sure that everything is tagged/styled/marked properly in Word, it should save to PDF with the correct tags and such.
I realise this question has been asked many times before but a lot of them are old now without an answer.
I have a need for users to be able to edit word documents from my web page.
Are there any editors, or components, that will allow me to do this?
A bit of background, the user will be able to upload a word document to my site and then view/edit it from there. There will be no requirement for the user to download the document again but ideally I'd like to keep the document as a word doc at my end.
Cheers
A little pricey, but the .NET Server version of TX Text Control allows editing of .doc and .docx documents within a browser. (I have the standalone .NET Pro version.)
Here's a much cheaper one: Cute Editor, but I have never used it.
Well, you can do what you want with the OpenXML SDK and some XSLT (you can convert to/from docx or WordML to html) but it's not easy, and you'd have a great deal of difficulty retaining fidelity if you have much more than very simple documents.
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)
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm working on a project which stores single images and text files in one place, like a time capsule. Now, most every project can be saved as one file, like DOC, PPT, and ODF. But complete web pages can't -- they're saved as a separate HTML file and data folder. I want to save a web page in a single archive, and while there are several solutions, there's no "standard". Which is the best format for HTML archives?
Microsoft has MHTML -- basically a file encoded exactly as a MIME HTML email message. It's already based on an existing standard, and MHTML as its own was proposed as rfc2557. This is a great idea and it's been around forever, except it's been a "proposed standard" since 1999. Plus, implementations other than IE's are just cumbersome. IE and Opera support it; Firefox and Safari with a cumbersome extension.
Mozilla has Mozilla Archive Format -- basically a ZIP file with the markup and images, with metadata saved as RDF. It's an awesome idea -- Winamp does this for skins, and ODF and OOXML for their embedded images. I love this, except, 1. Nobody else except Mozilla uses it, 2. The only extension supporting it wasn't updated since Firefox 1.5.
Data URIs are becoming more popular. Instead of referencing an external location a la MHTML or MAF, you encode the file straight into the HTML markup as base64. Depending on your view, it's streamlined since the files are right where the markup is. However, support is still somewhat weak. Firefox, Opera, and Safari support it without gaffes; IE, the market leader, only started supporting it at IE8, and even then with limits.
Then of course, there's "Save complete webpage" where the HTML markup is saved as "savedpage.html" and the files in a separate "savedpage_files" folder. Afaik, everyone does this. It's well supported. But having to handle two separate elements is not simple and streamlined at all. My project needs to have them in a single archive.
Keeping in mind browser support and ease of editing the page, what do you think's the best way to save web pages in a single archive? What would be best as a "standard"? Or should I just buckle down and deal with the HTML file and separate folder? For the sake of my project, I could support that, but I'd best avoid it.
My favourite is the ZIP format. Because:
It is very well sutied for the purpose
It is well documented
There a a lot of implementations available for creating or reading them
A user can easily extract single files, change them and put them back in the archive
Almost every major Operating System (Windows, Mac and most linux) have a ZIP program built in
The alternatives all have some flaw:
With MHTMl, you can not easily edit.
With data URI's, I don't know how difficult the implementation would be. (With ZIP, even I could do it in PHP, 3 years ago...)
The option to store things as seperate files just has far too many things that could go wrong and mess up your archive.
It is not only question of file format. Another crucial question is what exactly you want to store? Is it:
store whole page as it is with all referenced resources - images,
CSS and javascript?
to capture page as it was rendered at some point in time; a static
image of some rendered state of web page DOM?
Most current "save page as" functionality in browser, be it to MAF or MHTML or file+dir, attempts the first way. This is ultimately flawed approach.
Don't forget web pages there days are rather local applications then a static document you can easily store. Potential issues:
one page is in fact several pages build dynamically by JS, user interaction is needed
to get it to desired state
AJAX applications can do remote communication with remote service rendering it
unusable for offline view.
Hidden links in javascript code. Such resource is then not part of stored page.
Even parsing JS code may not discover them. You need to run the code.
Even position of basic html elements may be recomputed may be computed dynamically by
JS and it is not always possible/easy to recreate it locally.
You would need some sort of JS memory dump and load this to get page to desired state
you hoped to store
And many many more issues...
Check Chrome SingleFile extension. It stores a web page to one html file with images inlined using already mentioned data URIs. I haven't tested it much so I cannot say how well it handles "volatile" ajax pages.
PDFs are supported on nearly all browsers on nearly all platforms and store content and images in a single file. They can be edited with the right tools. This is almost definitely not ideal, but it's an option to consider.
Use a zip file.
You could always make a program/script that extracts the zip file to a temp directory and loads the index.html file in your browser. You could even use an index.ini/txt file to specify the file that should be loaded when extracting.
Basically, you want something like the Mozilla Archive format, but without the unnecessary rdf crap just to specify what file to load.
MHT files are good, but they usually use base64 to embed files, which will make the file size bigger than it should be (data URIs are the same way). You can add attachments as binary, but you'll have to manually do that with a hex editor or create a tool and support for it by clients might not be as good.
Of course, if you want to use what browsers generate, MHT (Opera and IE at least) might be better.
i see no excuse to use anything other than a zipfile
Well, if browser support and ease of editing are the biggest concerns I think you are stuck with the file+directory approach unless you are willing to provide an editor for the single file format and live with not very good support in browsers.
You can create a single file by compressing the contents. You can also create a parent directory to ease handling.
The problem is that html is bottoms up not top down. Look at your file name which saved on my box as "What's the best "file format" for saving complete web pages (images, etc.) in a single archive? - Stack Overflow.html"
Just add a '|' and one has trouble doing copy and paste backups to a spare drive. In the end you end up. chopping the file name in order to save it. Dozens/ perhaps hundreds of identical index.html or index.php are cluttering my drives.
The partial solution is to write you own CMS and use scripts to map all relevant files to a flat file database - then use fileName, size, mtime and md5 to get a unique Id for each file. Create a flat file index permitting 100k or 1000k records. The goal is to write once and use many times. So you need a real CMS you need a unique id based on content (eg index8765432.html) that goes in your files_archive. Ditto for the others. Then you can non-destructively symlink from the saved original html to the files_archive and just recreate the file using a php or alternative script if need be. Don't know if it will work as I'm at the same point you're at - maybe in a week will know for sure. The more useful approach is to have a top down structure based on your business or personal wants and related tasks. So your files might be organized top down but external ones bottom up to preserve the original content. My interest is in Web 3.0 services and the closer you get to machine to machine interaction the greater the need to structure the information. Maybe time to rethink the idea of bundling everything into a single file. So you have hundreds of main.css why bundle when a top down solution might let you modify one file instead of hundreds.