Best Browser For Using Complex Web Applications? 347
yanyan writes "I'm fairly new to the field of web application development. Currently I'm working on a big online ticketing system for passage and freight for a local shipping company. It's a one-man show and the system is written in Ruby and uses Rails. Aside from the requisite functionality of creating bookings the system must also print reports and tickets, and this is where I've discovered (the hard way) that most, if not all, browsers fall short. I've had to switch from Firefox 3.6.3 to Opera 10.53 because of a major printing bug in Firefox, but the latest stable Opera is also giving me its own share of problems. To complicate things, an earlier version of Opera (10.10) doesn't appear to have 10.53's printing problems, but I'm wary. What browsers and specific versions do you end up deploying for use with big, complex web apps that include printing? Also consider CSS accuracy and consistency."
but I thought HTML was supposed to fix all that? (Score:5, Insightful)
Hahaha, I kid, I kid. If your interface is complex, why are you using HTML/CSS/Javascript/etc? Why not take advantage of a more advanced and mature UI widget set, such as that provided by Java or *shock* the native environment?
The web is about where MacOS was 20 years ago in terms of ability to deliver a rich application UI experience. Google are excellent at marketing it as some sort of advance, but it really isn't. Don't shoehorn.
Re:but I thought HTML was supposed to fix all that (Score:5, Informative)
Why not take advantage of a more advanced and mature UI widget set, such as that provided by Java
Java is 20 years old, Javascript is 15 years old, and Java is mature while Javascript is not? Does that extra 5 years really make that much of a difference? Was Java considered not mature in 2005? There are plenty of mature Javascript UI libraries around that developers can take advantage of (ExtJS/Sencha, jQuery, Mootools, etc). There are several use cases where Java is a pain in the ass and an offline application is not an option. A rich internet application implemented in Javascript is perfectly fine for many situations. There's no shoehorn involved when it's the best tool for the job.
Re:but I thought HTML was supposed to fix all that (Score:5, Insightful)
For recent programming languages, 5 years is a lifetime. Compare Java now to Java five years ago, or Javascript now to Javascript five years ago.
Re:but I thought HTML was supposed to fix all that (Score:3, Informative)
The big difference is that all the browser has to do for java is host the runtime. For javascript, the browser has to support the entire instruction set. Java takes longer to start. But once it has started, it gives you much more control.
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
Can you define that term? I have seen it used to refer to half a dozen vaguely related concepts so far, so it would be nice to know which one you are referring to.
"There's no shoehorn involved when it's the best tool for the job."
The web is not the best tool for every job though, which I think was OP's point.
Re:but I thought HTML was supposed to fix all that (Score:5, Informative)
I will be flayed alive, but Silverlight 4 is a "Rich Internet Application" framework and with the most recent version, they built in some very tight and effective printing functionality. That, in combination with the ability to pretty much lay things out exactly as you want, export to an image or text format, export the app to an out of browser desktop app, and print in whatever format you see fit, makes it ideal for the kind of ticketing system you're talking about.
Here's a blog on how to implement it: http://wildermuth.com/2009/11/27/Silverlight_4_s_Printing_Support [wildermuth.com]
And another: http://www.silverlightshow.net/items/A-look-at-the-Printing-API-in-Silverlight-4.aspx [silverlightshow.net]
and here's Microsoft's page hyping it: http://www.silverlight.net/getstarted/silverlight-4/ [silverlight.net]
Here's a blog on linking Ruby on Rails with Silverlight as well: http://techblogging.wordpress.com/2008/03/26/using-silverlight-with-rubyonrails/ [wordpress.com]
Hope this helps.
Re:but I thought HTML was supposed to fix all that (Score:5, Interesting)
I would say about 75% of my time at work is spent working around inconsistencies and bugs in Silverlight. To be fair, I've only tried 3, not 4, but they really should have called it "Silverlight Beta 3", not "Silverlight 3". It works flawlessly cross-browser (with a few odd, rare exceptions), and it seems like a big leap forward from HTML/JS for this sort of thing, but I have to say it's not quite ready to compete with desktop solutions.
However, if you absolutely must have it run in a browser and don't want to use hokey Java applets, Silverlight is something you should really look into.
Re:but I thought HTML was supposed to fix all that (Score:4, Informative)
NONE of you posting in this thread section can read, obviously. The question is what BROWSER is best for complex web applications. It is NOT what programming/scripting language is best for making such applications.
Heck, as wrong of an answer as it would be, "Internet Explorer would be best!!!" would be a better answer than the ones you all are fighting over. At least it's on the list of possible answers to the question.
Someone needs to mod you all to Off Topic oblivion. There's nothing "Insightful" in you all not even remembering what the question was...
Re:but I thought HTML was supposed to fix all that (Score:5, Insightful)
If an engineer is asked, "What is the best tractor for me to commute to my office every day in?" one of the first questions should be, "Why do you need a tractor?"
Even if you find out that the man really needs a tractor and isn't just lacking knowledge of alternative automotive technologies, you'll have learnt more about his specific requirements in the process.
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
What are you smoking? The whole point of the web is that it can run on almost every platform out there. Phones, web tvs, Linux boxes, PCs, etc...
Silverlight, as nice as it may be, will never be able to compete on that front. Look at where flash is today.
As you say, if you absolutely must have it run in a browser, write it in HTML/js/css. That's what browsers understand.
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
The root of this story is about a guy trying to solve a specific internal application problem – not a widely distributed and publicly available application. And, he is writing the application in Ruby, which is good for web development.
However, I think that I would have written a native application to the platform that they are using instead of a web application.
Re:but I thought HTML was supposed to fix all that (Score:3, Informative)
I could say I didn't want to burst your bubble here, but I do. Pop. Consider it burst.
Try to do what most software developers do once. Go into a company that has very complex requirements for their application. Try to do it in any of the more popular web-technologies today, Richfaces, JSF, Struts (you can see where I am coming from I guess) and develop this vertical LOB app. Sorry to tell you, you will spend at least 5-10 times as much time to get it to work than if you use something like Silverlight or Flex and put a SOAP interface on your server. Not only that, but it will easily scale 100 times better than you can possibly manage with an app that keeps all state on the server including conversation state.
In typical LOB apps you can easily cut network traffic and server hits by 50-90% over an Ajax solution by going with Flex or Silverlight. In most cases such things matter. Not for toy applications though.
Re:but I thought HTML was supposed to fix all that (Score:5, Interesting)
Maturity isn't defined by the number of years since conception, but by its origins and the development and engineering which has gone into it since. HTML/Javascript has only comparatively recently been considered as a serious app development platform to contend with native apps, still building on the hypertext + scripting language paradigm. Even Google knows what a pain it is to work with HTML/Javascript directly and has developed a translator from Java to implement their web apps.
What's more, there are very few use cases where an offline application (I assume by that you mean "not HTML/Javascript" - I'm not sure what's "offline" about Java) isn't an option. The basic selling point with HTML apps is that you don't have to spend 30 seconds downloading and installing a small binary. When you're writing for a corporation, that's reduced to insignificance because it'd be installed as part of the deployment procedure.
Re:but I thought HTML was supposed to fix all that (Score:3, Informative)
Not that I disagree with you, but there are plenty of offline applications written in Java, using Swing. Java is not limited to applets and application servers, there is a mature library for standalone/offline application development. As I remember things, the reason we do not see more desktop applications written in Java is the bad reputation Java had in the 90s for taking a long time to loa, and to some degree the fact that Swing does not integrate with the desktop look and feel (or at least it did not the last time I checked, which was admittedly years ago).
Re:but I thought HTML was supposed to fix all that (Score:4, Insightful)
I'm sorry but you have confused HTTP/HTML/Javascript with the internet.
The fact is that this trend of using the browser as an interface is nothing less than having a hammer and treating everything as a nail.
Re:but I thought HTML was supposed to fix all that (Score:3, Interesting)
after close to about 12 years of developing for the web - from perl CGI scripts to PHP, Java JSP - JSF, python, RoR and various other related things I've finally given up on browser based apps. I do use HTTP/JSON for an interface between the server side and the client side. That allows the server side to be used from AJAX frontend or from a Java desktop app or what have you. But a strict browser based software - never again.
For a 'rich' client app I would use either: Qt (python/ruby/c++ in order of preference), Java or even VisualWhatever (if I were tied to windows - I try to keep it cross platform).
Javascript, GMFB (Score:2, Informative)
Forget the comparison of years of age. "Javascript" and "mature" are not words which in any sense could ever be considered compatible. After one hundred years, Javascript will still not be a mature language. It is crap by its nature.
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
Javascript is mature enough, it is the DOM that needs to evolve and be consistent over the different browsers. And CSS.
Still, I'm not always convinced making everything a web application is an efficient choice...
+1 Insightful (Score:2)
Re:+1 Insightful (Score:2)
The wheel is reinvented in computer science every so often.
With the web, it's reinvented veeeeeeerrrryyyy slowly. At this rate, it'll pass Windows 3.1 in about fifteen years.
Re:but I thought HTML was supposed to fix all that (Score:2)
Beyond this, having a web interface allows you to switch client architectures fairly easily as long as you aren't too tied to one, which is the path many internal development efforts went towards in the later 1990's and early 2000's with IE5 and IE6. Frameworks like ExtJS offer a lot of rich functionality in web based applications. I would even suggest going with XUL over Java or
Re:but I thought HTML was supposed to fix all that (Score:2)
HTML, by design, Is Not a fixed-layout page description language. This is one of its great virtues. Assuming the designer doesn't muck it up, it should reflow nicely, or at least adequately, onto a variety of monitor shapes and sizes, and browser capabilities. However, that makes it a pretty terrible substitute for PDF in any situation where you want to spit stuff onto standard sized paper in a precise way.
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
>The web is about where MacOS was 20 years ago in terms of ability to deliver a rich application UI experience.
Don't insult the mac like that. There were Mac apps back in 1984 that you can still only badly mimic via a web "application."
The fact is that a web browser is an application that retrieves and renders hypertext documents over a network, and nothing more. Just because it has scripting and the web can make available documents to huge numbers of people, too many people think they can shoehorn any kind of application in to it.
There is a huge demand for data entry and reporting (both viewing and printing) that web browser just aren't up to. If web browser ever get to the point where they have drag-and-drop form/report creation with a user interface that can be reliably delivered to client computers then great. Until then there needs to be something else to fill this void, and there just isn't. There used to be some very nice client/server GUI form and reporting tools back in the 90s, but most of those have devolved in to half-assed web tools with insane setup, configuration, and support requirements (and usually exorbitant enterprise pricing to boot).
Heck, the last time I checked no web browser could even reliably be told automatically to print a page landscape!
Re:but I thought HTML was supposed to fix all that (Score:3, Interesting)
Don't insult the mac like that. There were Mac apps back in 1984 that you can still only badly mimic via a web "application."
You're right. I'm forgetting the beauty, simplicity and consistency of the 1984 Mac. I've been using the comparative UI mess that is OS X for too long.
There used to be some very nice client/server GUI form and reporting tools back in the 90s
The whole display / presentation / business client / business server / database multi-tier thing seems to have been broken horribly, so now presentation, business client and business server are merged on some cloud and delivered to a dumb graphical display. Why? Well, to take away control, of course.
Re:but I thought HTML was supposed to fix all that (Score:2)
By the way: Why don’t we replace the browser with a window containing tabs of virtual machines that un-freeze a tiny local memory image containing common libraries (also for backward compatibility) that can run remote executables, either as a thin client or as a real application.
Then we only have to have the ability to separate tabs our to being their own windows and having the ability to have an icon in your start menu.
And suddenly we have the best of both worlds: Complete encapsulation, simple development for simple projects with XHTML/CSS/JS/..., and the ability to run full applications.
Done right, it should also be faster than JS or a VM running a full OS.
Maybe I should talk to the Firefox team about it. Or the VirtualBox guys?
Re:but I thought HTML was supposed to fix all that (Score:5, Insightful)
Apps like MET (link [picnet.com.au])
Yes, privacy implications are another great reason to avoid web apps.
Google Apps - YouTube
QED. All of these are pale imitations of native apps when it comes to feature sets, responsiveness and UI.
There has to be huge reasons to abandon web for native development.
Other way round, dude.
Java lost the applet battle about 5 years ago.
What does that even mean? Google Apps are mostly written in Java and translated, so clearly the largest web app producer on the planet likes the language (just not the level of control a client could maintain if Google actually deployed Java). Java is still going to execute faster than HTML/Javascript - hell, we're only just starting to see hardware 3D acceleration, something Java's had since 2001. If you're about to bitch that Swing is ugly, it can be skinned, or you can use SWT which builds on top of native widgets.
Of course, this is just an argument that Java is better than HTML/Javascript for client/server apps; the best solution is whatever gives the user the richest client experience, employing a domain-specific remoting protocol (e.g. IMAP for e-mail) for transferring information between client and server at the business rather than presentation level.
Java lost the applet battle about 5 years ago. JavaScript is now a powerful full fledged language that is FAST!!!
Your definition of "fast" is a comparison with last year's Javascript interpreter/compiler. My definition of "fast" is comparing responsiveness of a whole native app vs a whole HTML/CSS/Javascript app.
Html5 + CSS 3 is an incredibly powerful, flexible
Compared to what? HTML4 + CSS2? Yes, in theory - pity it's not actually implemented fully or stably by any browser yet, just like all recent W3C standards (whence the OP's problem).
Compared to native Windows / Cocoa / Java UI? No.
and extremely easy to use
You need to try Xcode. Or its older (and wiser) sibling, Smalltalk. That is easy to use.
So Ignore what idiot poster posted above
If I had a hammer, I'd hammer in the morning...
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
Don't compare the weaknesses of AJAX against the strengths of client side developments without at least mentioning the other way 'round, mmkay?
Client side applications have issues such as:
1) System requirements! You have to have the right type of computer, with the right type of processor and/or O/S, etc. Don't have one? Well you are SCREWED. Porting a client application from one platform to another, even with a decent toolkit can be daunting. Even if the programming language supports cross platform development, does that "cross platform" part include Linux? What about QNX? What about the iPad? Browser-based computing eliminates most of this problem.
2) Environmental differences! Software that works well on computer A might not run at all on computer B despite them being very similar because B installed a shareware program that updated some DLL. Good luck sorting that one out? Web-based applications don't really have these problems outside of the browser discrepancies that exist when you don't write an app with a decent abstraction API (EG: Prototype)
3) Data locality! So you are at work, you save your file, and then you leave. Over the weekend you remember some detail that you want to bang into your document quickly before you forget. Don't have your laptop with you? Well, shucks! Web-based applications don't really have these problems, either. You might have trouble with Internet connectivity, but even in very rural areas this problem is disappearing rapidly.
4) Cheap development! Web developers are easy to come by! The standards are open, the needs are many, and the work is easily commoditizable and thus hiring help isn't so difficult.
Re:but I thought HTML was supposed to fix all that (Score:3, Interesting)
System requirements! Browser-based computing eliminates most of this problem.
When degraded interface, latency of processing and (depending on who's deploying the servers) privacy aren't important... still often no. See the fine article for a counterexample.
Even if the programming language supports cross platform development, does that "cross platform" part include Linux? What about QNX? What about the iPad?
Linux - usually.
QNX - with this RTOS built for embedded apps you clutch at straws. But there's a desktop environment and QNX 6.4 included an albeit non-current Firefox 3, you'll say, then 6.4.1 decided to include a Webkit port last year, you'll point out. Well, yes - tell me, have you tested a modern web app on QNX? Now what about a Java app, or an OpenGL app?
iPad - Steve's a clever bastard, and has intentionally crippled this platform so you have the choice of either providing a degraded HTML/Javascript experience or developing for Apple's proprietary Cocoa framework. In this specific case, there's little developers can do except stop jumping on the shiny bandwagons Apple are driving toward the firing range.
Amiga - I'm including this one because I think you forgot it. A recently released Timberwolf alpha (Firefox port) for AmigaOS surely has to be an argument for web apps.
Environmental differences! Software that works well on computer A might not run at all on computer B despite them being very similar because B installed a shareware program that updated some DLL.
Oh Christ, the horror of checking a DLL/so version and/or providing my own in the app directory! You're thinking of problems with DLL sharing and system DLL overwriting which were largely eliminated by Windows 2000. FUD is bad, ok?
the browser discrepancies that exist when you don't write an app with a decent abstraction API (EG: Prototype)
This? [prototypejs.org] It's a combined utility and occasional kludge layer, like padding for a kick in the balls. Compiling 160k of fixup source to visit a web page - that's what I want my CPU to waste time doing!
Data locality! So you are at work, you save your file, and then you leave.
Yeah, you'll have that file stored on a company network server somewhere which you can access securely from a remote location. You'll also have a locally cached copy. This will all be set up in a few minutes as part of the equipment deployment process in any competent IT department.
You might have trouble with Internet connectivity, but even in very rural areas this problem is disappearing rapidly.
Argh. Most of the world is a very rural area, and it's not disappearing rapidly because there is no profit in providing cheap connectivity to very rural areas. It's not as if you have to go to a third world country - just the most densely populated country in Europe [slashdot.org]. I'm not buying a satellite phone for your stupid web app, thanks.
Meanwhile, in the cities, (1) an business ISP can and will go down for a few hours (and routing be dodgy, and app servers have problems), and it'd be commercial suicide if your workforce suddenly couldn't do anything but twiddle its thumbs; (2) in general, disaster planning means you don't rely on global infrastructure and political stability except when you need to.
4) Cheap development! Web developers are easy to come by! The standards are open, the needs are many, and the work is easily commoditizable and thus hiring help isn't so difficult.
Ah, the "why choose Windows" argument. This isn't 1995. There are plenty of programmers available and proficient with common APIs beyond HTML/Javascript.
IE or Firefox (Score:5, Insightful)
Figure out what you need to do with your application to make it work in IE and Firefox is the only real solution.
Re:IE or Firefox (Score:3, Insightful)
The real world answer is go ignore IE and let all the people still using it go cry.
Re:IE or Firefox (Score:2, Insightful)
Actually, the real world answer is design it for IE. If it works in IE then it will work in everything else. Besides, the JavaScript debugger in IE (Visual Studio) is vastly superior to Firebug, and yes, I've used both... I just don't suck the open source/free software ****.
Re:IE or Firefox (Score:2)
Well, if you are going to be like that, I do. Fuck IE, I don't care who uses it. I'm not, and my intended audience shouldn't either.
(I'm not a developer though, so "fortunately" you don't have to deal with my opinion in any real manner)
Re:IE or Firefox (Score:3, Insightful)
The real world answer is go ignore IE and let all the people still using it go cry.
That's not a "real world answer". That's an absurd geek fantasy. Love it or hate it, most people still use IE [wikipedia.org].
If you're a web developer, you cannot afford to ignore that your users will make choices about which browser they use that may be different than your own.
Re:IE or Firefox (Score:3, Informative)
You are assuming it's for mass-consumption. Take a look at the actual post, and you'll see it's an internal application.
Re:IE or Firefox (Score:3, Insightful)
The real world answer is go ignore IE and let all the people still using it go cry.
.
No that is not the real world answer. If you don't get your application working in IE, the people will go find one that does. You might get away with not working in IE if your only designing for the tech crowd, but if your designing for business or the public, then your killing your own business before it's started.
Re:IE or Firefox (Score:2)
Re:IE or Firefox (Score:2)
Alternatively, if Firefox has bugs, has he filed a bug report?
Re:IE or Firefox (Score:3, Informative)
Sure you may be trying to do things the right way, i.e. fully standard compliant, but it isn't the real world answer.
I managed to write a web application a couple of years ago that not only displayed consistently in IE and Firefox, but also printed consistently from both of them, while remaining standards-compliant and not using HTML or CSS hacks. The printing was by far the harder part - the browsers initially returned very different printed results even though they rendered the page on-screen almost identically. Changes to the CSS would frequently fix the printing of one while breaking the other, yet not affecting the on-screen rendering of either.
I can see why people who do a lot of printing lean towards PDF.
Re:IE or Firefox (Score:2)
From the summary "What browsers and specific versions do you end up deploying"
That sounds to me that they're *deploying* a specific browser to a specific client desktop. That it may work in 'the real world' would seem a moot point.
That said, avoiding too many browser-specific hacks may ensure a smoother upgrade path when deploying, say, version 3 to Chrome9.1 sometime in the future. (But hardly answers the question of which browser *today* prints best.)
Re:IE or Firefox (Score:3, Insightful)
I’m a long-term professional, and if you are developing for any specific browser, you are a failure, and not a professional.
The goal is to know the W3C standards by heart in every minute detail (yes, it can be done, since I did it for years without problems), and design to it. In a way that allows you to spot things where not you are wrong, but the browser is!
You only add browser-specific quirks after you’re done. Separated from the main code wherever possible.
Otherwise you end up with a huge non-working mess as soon as you notice that your nice giant backbone of your webapp only works because of a quirk/bug/weirdness of that specific browser.
Things like http://code.google.com/p/ie7-js/ [google.com] greatly help with this. :)
My experience: (Score:5, Informative)
In my experience, the easiest way to get a consistent and stable printing experience is by generating PDF. I have yet to have stability problems if this is done properly. As you're working with Ruby on Rails, using Prawn and Prawnto might be useful. However, if you absolutely positively must NOT use PDF for printing, then this probably won't help you.
Re:My experience: (Score:5, Insightful)
PDF gets used for all kinds of wrong reasons - I freaking loathe web designers who think a PDF is an appropriate substitute for a web page - but printing is the one place that PDF shines. Just make sure the user can easily and intuitively specify the paper size and you should be good to go.
Re:My experience: (Score:3, Insightful)
If the user is printing out standard forms to be used in shipping the last thing you want to do is let the user change the paper size.
Re:My experience: (Score:5, Insightful)
He should at least make sure the form works with both A4 and Letter size papers, otherwise the company will be in for quite a shock when they decide to expand their business outside the US and find that the most common reaction to mentions of letter size paper is "Letter size? Is that what you call A4?".
Re:My experience: (Score:3)
You never target foreign customers, until you do. Then it's too late.
Re:My experience: (Score:2)
If the user is printing out standard forms to be used in shipping the last thing you want to do is let the user change the paper size.
The user already gets to decide what paper is in the printer.
Re:My experience: (Score:3, Informative)
Just please give the Windows users a link/suggestion to download a good PDF viewer, or at least anything less evil than Acrobat Reader.
Re:My experience: (Score:2)
I will second this. PDFs are THE solution for printing, or even sharing strictly formatted documents, even electronically.
Re:My experience: (Score:3, Interesting)
Re:My experience: (Score:3, Informative)
If we hadn't done a huge amount of form design around PS I'd switch em to PCL and be done with it.
I've had pretty good luck printing postscript to non-postscript printers using ghostscript as a filter. These days it's not even that computationally intensive, all things considered.
Re:My experience: (Score:2)
Re:My experience: (Score:5, Insightful)
Absolutely agreed.
Anything mission-critical like printing a ticket should absolutely NOT use something that could cause the whole system to break down when a single trivial update happens. HTML wasn't designed for printing, and it never will be. The browser is just a band aid put on top of a fundamental disconnect in technology and application.
I'd even go so far as to say that unless you're outputting and printing from PDF or some other well defined and standardized print format, don't proceed any farther. You'll pay more for the problems down the road when the whole she-bang doesn't work for some dumb reason.
Re:My experience: (Score:2)
Re:My experience: (Score:2)
It may also be worth noting that this is exactly the solution that no less minds than those at Google settled on. When you "print" in Google Docs, you get a PDF that you can print from the local machine's native print faculties.
-Peter
Re:My experience: (Score:2)
I agree with using PDF for print consistency, I've used the pdf-writer gem in my Rails apps.
On the other hand, I've never had a problem with printing and print stylesheets in Firefox, and have used that solution whenever I don't need pixel-accuracy in my printouts.
Re:My experience: (Score:2)
If you don't want to learn Prawn and are more comfortable with HTML, use something like PDFKit [github.com], which is a wrapper around wkhtmltopdf [google.com], which basically just packages WebKit for PDF printing. You'll be able to use CSS3 and other niceties and it'll be consistent, since it's creating a pdf. Perhaps you can do better things with Prawn, but I guarantee that writing moderately complex reports will be easier with PDFKit then with Prawn.
Re:My experience: (Score:2)
Stop using the browser for print (Score:5, Insightful)
Re:Stop using the browser for print (Score:2)
XML, as in XHTML?
Re:Stop using the browser for print (Score:2, Insightful)
Re:Stop using the browser for print (Score:2)
I'll second this. Look around and found some decent F/OSS PHP libraries to generate PDF documents. They do exist, and works well enough. This is what I had to do for an inventory management system that I develop for a client.
Chrome, PDF (Score:5, Insightful)
Even though I don't use it for development, I've got several of my clients using Chrome to take advantage of the Javascript engine. My applications use a lot of Javascript for the interfaces, and Chrome speeds up the rendering of large data sets compared to IE or Firefox.
For printing, the only solution to keep you sane is to export reports as PDF and let them print through their reader. That's specifically what PDF is for (consistency in displaying and printing). Depending on the report, they may also appreciate a CSV version that they can do their own filtering and sorting on.
Lynx! (Score:2, Funny)
Writing to a specific browser... (Score:5, Insightful)
...is a much more serious bug than any possible printing problem.
Re:Writing to a specific browser... (Score:3)
...is a much more serious bug than any possible printing problem.
I'd say mod parent up, but other people recognize the wisdom and have done so already.
Do not write a web application tied to a particular browser, or even two particular browsers. You will repeat mistakes made 15 years ago when people used to do the same thing for Internet Explorer or Netscape. Those who come after will curse your name forever.
Remember all those sites that used to say "Best viewed in IE5" or "Best viewed in Netscape"? You don't want that.
Re:Writing to a specific browser... (Score:2)
Punch in the eyeball (Score:5, Insightful)
This is a classic example of a developer trying to tailor the user to the system instead of the system to the user.
Stop your whining and just make it work in one or more of the common browsers. I have been forced to bend crap environments to my will and I suspect that most developers around slashdot have bent bad systems until they cried; but made them work in the end.
Re:Punch in the eyeball (Score:2)
Re:Punch in the eyeball (Score:2)
Wish I had mod points, parent is absolutely correct. Stop complaining and trying to find some panacea for your architecture problems. It seems you want to have something you can show your client 'There! it works on THAT browser!' instead of thinking about the common denominator. There's no way I'd be happy having to use not just a particular browser, but a particular version of that browser - who are you trying to kid? The client and the user, it seems. Sorry if this seems harsh but that's my opinion.
+1 Insightful. Browsers make decent end user solutions for light web apps, but finding an enterprise class solution that will only work for one build on one browser is like telling golfers they all have to use the same set of clubs to complete a course. It will not go over. No matter how 'great' it looks in X build of Y browser. Don't tie your application down to a specific environment; understandably web design is like trying to make a shoe that fits everybody, but making everybody else lop off toes to fit your shoe only pleases you, and pisses of scores of users in the process.
Standards are only a guideline these days unfortunately, and one of the required skill-sets of an, dare I use a synergy-istic word, 'agile' developer is the ability to transcend the difficulties despite the simplicity of choosing the easier route for yourself, and designing a solution that fits a general environment.
You wouldn't purchase the most bad-ass truck in the world, but on the stipulation that it could only go off-roading on Sundays between 2-8pm, during full moons, on the first Tuesday of every month. On the other hand, if your employer / client would purchase this truck, well, get-in, get-out, and get-paid, unless you want the possibility of feature creep out the ass and the maintainability nightmare of supporting a specific platform on a specific day of the week.
Re:Punch in the eyeball (Score:5, Interesting)
I have been forced to bend crap environments to my will and I suspect that most developers around slashdot have bent bad systems until they cried; but made them work in the end.
I bent and bent, then cried and gave up and I had to tell my users to use IE. There's a table printing bug from 2005 that is still open, though fortunately my specific flavor of printing problems (entire rows of data going missing at page breaks) eventually went away several versions after firefox 2.
Nowadays I use PDF, though several PDF generation libraries I've tried had serious deficiencies like being unable to tell me how much space a block of text will take before it places it on the page, or being unable to override Acrobat Reader's default printing settings, which fuck up anything you're trying to print onto an existing form. (I hacked it into fpdf once, but it was essentially a copy-and-paste of a command from another pdf that was able to force me to print with auto-fuckup-and-center turned off. It worked for me and my version of reader, but I didn't dare put it into production since I had to change the spec version fpdf inserts into the header (1.3) to one that supported overriding the printer options).
If your reports don't need anything too fancy and they already pop out in HTML, you can use html2ps | ps2pdf to get something kinda resembling the original webpage. You can't make it look pretty and I'm fairly certain it's text only, but it'll print out exactly as it appears no matter what browser you are using.
There's no "best" answer here. (Score:2)
Next time around though, write the app better. Export to PDF/PS if you need formatting to be absolutely preserved.
Define "printing problems" (Score:2)
What are the "printing problems" you're having?
If the problem is that you're having trouble making things look the way you want to (you mentioning printing bookings, which I suspect might need a very rigid format), you're not going to get away from that. HTML is designed to allow variation by browser implementation and by user preference. It's not supposed to look the same everywhere.
If you need accurate, precise print reproduction everywhere, your best bet is to generate some kind of PDL (Page Description Language) on the fly. PDF is the common choice here, and prolly your best bet, since most people are used to it and already have software. Other choices would be PostScript and XPS, but those are much less commonly available in the user community.
Note that "PDF" doesn't have to mean "Adobe"; there are tons of third-party PDF tools out there, including free and FOSS.
Or export PDF, PS, etc. (Score:2)
Re:or just learn to use css (Score:2, Funny)
These kinds of issues are what Flash excels at-- uniform output. Why dont'cha push your final, scrubbed and parsed user data to a Flash widget to print? I believe there are all kinds of native PDF and print controls in the Flash API anyway.
To alll you HTML5 kool-aid drinkers, flame away. Tell me how the canvas tag will fix all the OP's woes.
Re:or just learn to use css (Score:2)
What print bug does Firefox have that's not actually just expected behavior
Well, there's this one [mozilla.org] that's been critical since 2005. At least they've fixed the truncation problems and missing thead/tfoot (comments say that 3.0 release candidates fixed the dataloss) but it still has weird border issues in print preview. (note the missing bottom edge of the input above the first sample table... at least on my windows xp print preview anyway, it's a shame that windows printing is really a function of how shitty your printer driver is.)
mediatype:screen vs print (Score:2)
yea...there's a reason why there's a media type definition for CSS.
Plus using javascript to load browser specific CSS so I don't have to rely on CSS hacks and also keeps things "valid"
Oh, and I dropped support for IE6.
IE7 is going soon too as IE8 becomes mainstream among IE users.
Still, I hate IE with a passion.
My main browsers are FF3.0x+/3.5+, Chrome/Safari, and Opera 9/10....in terms of testing.
PDF if at all possible. Otherwise coughFlashCough (Score:3, Informative)
The only way that anyone does proper printing of web documents is as PDFs, and to hell with the browser. This is for very good reason.
If your system absolutely must print from a web page, use Flash. Yes, I know. But it will print from within the page, it produces identical prints in all browsers/platforms, and everyone already has it installed.
PDF is the way to go (Score:2)
Output to a PDF document and have them print it out.
PDF is an open format. Go for it! Enjoy.
Flash is an OKAY solution, but the printer support is hopeless unless your users have downloaded and installed an AIR application.
Short answer: don't. (Score:2)
Re:Short answer: don't. (Score:2)
One thing missing here (Score:2)
that isn't clear from the description: Is this a tool meant to be used internally by the company or is it meant to be used by the general public?
Because if it's the latter, whatever your solution, it better work in every browser and not just specific older version of Opera.
Re:One thing missing here (Score:2)
that isn't clear from the description: Is this a tool meant to be used internally by the company or is it meant to be used by the general public?
Because if it's the latter, whatever your solution, it better work in every browser and not just specific older version of Opera.
It doesn't matter. You cannot guarantee what browser a user will have loaded today, much less a few years from now, whether it's in a corporate environment or not.
Oh really? (Score:2)
Most place I've worked at recently have firefox installed, except for that one pesky intranet webapp that only runs in IE6 (and higher if you're lucky!)
I'm not advocating the tie-in to a specific version of Opera. However, with an army of IT support personnel keeping things real, I don't see it should be a huge deal, given whatever other cruft they routinely install and maintain in an SOE.
(Assuming of course this application is locked down to an internal network)
The "Best Browswer"... (Score:2)
Use PDF (Score:2)
Generate PDF tickets on the fly. There are plenty of open source and commercial libraries to help you out.
As for a "major" Firefox printing bug etc: you're doing something wrong. I presume that's since you're new. I have an in house monstrosity that prints invoices (think tables, lots of lines and tight alignments) fine across the spectrum: from IE6 to every contemporary browsers. All using CSS and HTML. So it can be done, and I've yet to run into any printing bugs, major or otherwise. There are hacks to be sure, but nothing I consider to be browser bugs, more like specification bugs.
Re:Use PDF (Score:2)
The problem I had was that every browser had different printing preference settings.
Do background images print?
Are images scaled?
Do images print at 72dpi? 300dpi? the alt text?
Are fonts over ridden?
The list just went on and on.
Use a pdf library, it will save you time.
Make sure that you can embed the fonts in the pdf. otherwise you will be dealing with all sorts of stupid bug reports.
Try BrowserLab (Score:2)
Better write for all browsers (Score:2)
A third option... (Score:2)
Ok, I'm presuming that the problem is native browser printing. The printer section of CSS is the red headed stepchild of the spec with only Opera getting it remotely right. That leaves PDF which has been discussed. Given your description of the situation you might have a third option.
If you're building this for an in house company as it sounds and the server is onsite consider creating a Postscript file and then commanding the OS to print the file normally. This cuts the browser out of the equation entirely and lets you get very specific with the printer since you can use system commands to control it fairly directly (or even cURL to it if the printer runs a webserver - some do). This solution is only viable if you have a specific printer or printers you're using regardless of the location of the computer that is commanding the print job be done.
You've got it backwards. (Score:5, Insightful)
I think you've got it backwards. (Score:4, Insightful)
I really, really wish I could agree with you.
But there's a fundamental problem. An intractible problem, even.
Browsers simply try too hard to be all things to all people.
That's an impossible task without making all people conform to your definition of all people. Woops, totalitarian dictators and religious idealogues keep trying that one and finding it doesn't work either.
We should not be continuing to try to build or define the ultimate browser. We should, instead, be defining standards for browsers for specific application fields in specific countries.
Open standards, not standards led by any industry leader or special interest group.
Simple, standard browsers, implemented and implementable by small teams with unencumbered tools. With an overall API a single developer can grasp, and libraries that don't require teams just to find out where to find the answers.
Render to PDF (Score:2)
Forget about trying to make HTML into dependably formatted print output. Just use a library like Cairo to render what you want into a PDF and provide that to the users.
For printing use PDF via LaTeX (Score:5, Interesting)
I also develop for Ruby on Rails, and we have to support IE 6-8. (Of course the developers all use Firefox for Firebug)
For printing, I switched to using LaTeX, and returning the PDFs.
HTML just doesn't give you the kind of control that you need on a piece of paper.(Try having custom page headers/footers, for example) I ran into the bug in firefox where it would skip rows of a table going over a page boundry, and then there was other issues with it dropping images on other pages.
Plus, LaTeX just looks better. HTML is great if you don't know what it is going to be displayed on, but when you do know what kind of paper it is going to be displayed on, HTML isn't the best choice.
(Specifically, I used the rTeX plugin, with pdflatex)
Re:For printing use PDF via LaTeX (Score:3, Informative)
It's really easy to make LaTeX not look like an academic article: just use the right documentclass. If your file starts \documentclass{article} then you probably will find it hard to play with settings to make it not look like an academic article...
Re:For printing use PDF via LaTeX (Score:3, Informative)
The amount of work to make LaTeX not look like an academic article is boggling.
Then you're doing it wrong. The usual first trick is to make sure you've chosen the fonts right; most people don't understand the difference between styles and fonts and you sound ignorant enough to also make that blunder.
Hell, the amount of work just to figure out how the fuck you escape basic punctuation so your file compiles is boggling.
You have a library for that. Going all hair-shirt and doing it by hand is just foolish.
Just use a normal PDF library.
Depends on the size and complexity of the document being produced. If it's really rather large and complex, then build it as XML, use XSLT to map to XSL-FO, and then convert that to printable form. (IIRC, at least one XSL-FO system uses LaTeX as a back end...)
For starters (Score:2)
Don't even bother trying to use HTML to make printing work. Generate something else (pdf is good.. consistent, widely supported.. evil) and have the user print that.
This usually isn't a problem (Score:2)
had to write to or (in b2c) the website is expected to handle any browser the user might reasonably have, starting with IE6.
Screen versus print. (Score:2)
Re:Civility abounds (Score:2, Funny)
How about this then? What fucking printing bug?
Not reinventing the wheel?! (Score:2)
Now, if only more people thought this way.