Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Best Browser For Using Complex Web Applications?

timothy posted more than 4 years ago | from the fatal-error-encountered dept.

Firefox 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."

cancel ×

347 comments

Sorry! There are no comments related to the filter you selected.

but I thought HTML was supposed to fix all that? (4, Insightful)

FuckingNickName (1362625) | more than 4 years ago | (#32620784)

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 (0)

Anonymous Coward | more than 4 years ago | (#32620870)

Parent is onto something. The web is fundamentally the wrong approach. Just because you're familiar with hammers doesn't make them the best tool for all possible jobs. Sometimes you would be better served by a saw.

Re:but I thought HTML was supposed to fix all that (4, Informative)

amicusNYCL (1538833) | more than 4 years ago | (#32620920)

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 (4, Insightful)

Anpheus (908711) | more than 4 years ago | (#32620946)

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 (2, Insightful)

betterunixthanunix (980855) | more than 4 years ago | (#32620966)

"rich internet application"

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 (5, Interesting)

FuckingNickName (1362625) | more than 4 years ago | (#32621016)

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 (2, Informative)

betterunixthanunix (980855) | more than 4 years ago | (#32621074)

"I'm not sure what's "offline" about Java"

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 (0)

Anonymous Coward | more than 4 years ago | (#32621224)

Java's dead because people can never stop bringing up Applets.

Re:but I thought HTML was supposed to fix all that (3, Insightful)

DaveV1.0 (203135) | more than 4 years ago | (#32621268)

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.

Javascript, GMFB (1, Informative)

fnj (64210) | more than 4 years ago | (#32621378)

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.

+1 Insightful (1)

betterunixthanunix (980855) | more than 4 years ago | (#32620934)

The wheel is reinvented in computer science every so often.

Re:+1 Insightful (1)

Angst Badger (8636) | more than 4 years ago | (#32621004)

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:+1 Insightful (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32621108)

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.

To show my strong concurrence with this statement, I can say only one thing: niggers.

Re:but I thought HTML was supposed to fix all that (1)

aztracker1 (702135) | more than 4 years ago | (#32620964)

I don't think this is particularly insightful advise. A web interface works well, but regarding printing is a sore point. If they need particular printing enhancements, having a network accessible printer and the printing driven from the server may be better. Having the server issue a .pdf, or .ps set for the client to print would work too. Hell writing an extension for formatted printing would probably be ideal and I'd be surprised if nobody has an ns* extension for such a feature already written (though most will simply use PDF or PostScript directly).

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 .Net for this type of application myself. There are advantages to the centralized environment that browser based applications bring, namely a much lower cost for deployment.

Re:but I thought HTML was supposed to fix all that (1)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#32621442)

In the variety of web-based (or web-frontended) systems I've seen, it is somewhere between common and ubiquitous for any serious printing(ie. where fidelity matters, not where somebody just needs a bunch of text to scribble on or take to a meeting) to be handled by having the server spit out a .PDF, as you suggest.

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 (1)

slashchuck (617840) | more than 4 years ago | (#32621584)

I wrote a web-based certificate issuing app. The layout of the certificates was mandated by law. I have found that creating PDF's is the best way to ensure that printed output stays consistent with the report design requirements. Plus you can easily save them locally or email them with the assurance that the recipients will see the same report you designed.

Re:but I thought HTML was supposed to fix all that (2, Insightful)

linebackn (131821) | more than 4 years ago | (#32621252)

>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 (2, Interesting)

FuckingNickName (1362625) | more than 4 years ago | (#32621348)

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 (0)

Anonymous Coward | more than 4 years ago | (#32621262)

Lol yes, because if you ever happen to find a client-side Java application, the first thing that goes through your mind is how "advanced" and "mature" it is.

Reality is that users hate that gray dialog window shit. Make it look like facebook and they won't care if it's slow/buggy/can't print right. The Web Won.

Re:but I thought HTML was supposed to fix all that (1)

Hurricane78 (562437) | more than 4 years ago | (#32621570)

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?

IE or Firefox (4, Insightful)

ageoffri (723674) | more than 4 years ago | (#32620790)

Given that IE and Firefox pretty much set the standard, if you aren't developing for both of them then you are setting yourself up for failure. Sure you may be trying to do things the right way, i.e. fully standard compliant, but it isn't the real world answer.

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 (2, Insightful)

X0563511 (793323) | more than 4 years ago | (#32620854)

The real world answer is go ignore IE and let all the people still using it go cry.

Re:IE or Firefox (2, Insightful)

Anonymous Coward | more than 4 years ago | (#32621150)

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 (1)

X0563511 (793323) | more than 4 years ago | (#32621308)

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 (2, Insightful)

Anonymous Psychopath (18031) | more than 4 years ago | (#32621448)

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 (2, Insightful)

powerspike (729889) | more than 4 years ago | (#32621574)

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 (1)

LowlyWorm (966676) | more than 4 years ago | (#32620968)

Agreed. IE probably has the most consistent (and most available) documentation. Since I often use client side JS I usually start with FF. Everything should be tested in FF and IE. You may also want to be aware of cellphone users. If presentation is that critical write separate scripts server side for each browser. If not, you may get away with much less scripting.

Re:IE or Firefox (1)

blackraven14250 (902843) | more than 4 years ago | (#32620986)

That's only true if the system is used by travelers and not travel agents to allow for the bookings.

Re:IE or Firefox (1)

ta bu shi da yu (687699) | more than 4 years ago | (#32621154)

Alternatively, if Firefox has bugs, has he filed a bug report?

Re:IE or Firefox (2, Informative)

blincoln (592401) | more than 4 years ago | (#32621270)

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 (1)

ChunderDownunder (709234) | more than 4 years ago | (#32621560)

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.)

My experience: (5, Informative)

Roadmaster (96317) | more than 4 years ago | (#32620816)

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: (4, Insightful)

Jah-Wren Ryel (80510) | more than 4 years ago | (#32620868)

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: (2, Insightful)

FranTaylor (164577) | more than 4 years ago | (#32621006)

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: (4, Insightful)

mikael_j (106439) | more than 4 years ago | (#32621158)

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: (1)

Jah-Wren Ryel (80510) | more than 4 years ago | (#32621326)

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: (2, Informative)

DiegoBravo (324012) | more than 4 years ago | (#32621546)

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: (1)

Gr8Apes (679165) | more than 4 years ago | (#32620874)

I will second this. PDFs are THE solution for printing, or even sharing strictly formatted documents, even electronically.

Re:My experience: (2, Interesting)

afidel (530433) | more than 4 years ago | (#32620888)

The only problems I've had is how in relationship to certain HP printers using Postscript drivers, they'll occasionally run into problems with certain PDF's containing values that are valid in later PDF specs but not valid for PS. If we hadn't done a huge amount of form design around PS I'd switch em to PCL and be done with it.

Re:My experience: (2, Informative)

drinkypoo (153816) | more than 4 years ago | (#32621564)

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: (1)

aztracker1 (702135) | more than 4 years ago | (#32621010)

I have to totally agree here... PDF is probably the appropriate tool for the job... though if it's an internal application and the printers are network enabled, you could drive the printing from the server, which may work better. Either way, there will be some issues in place. It would be nice if there were an *easy* option in browsers to actually set the browser to *NOT* print the header/footer for certain sites, then have respectable print css options, and it could work well still... The biggest drawback I've seen in web apps is they will print with the header/footer, and not always respect the print css rules.

Re:My experience: (5, Insightful)

Vellmont (569020) | more than 4 years ago | (#32621032)

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: (1)

peterofoz (1038508) | more than 4 years ago | (#32621098)

Ditto. I wouldn't rely on HTML/CSS and browsers to render something to be printed. Use PDF or an image to provide reliability in printing. If you plan to use barcodes, I'd suggest either interleaved 2 of 5 or one of the 2-d barcode formats like PDF417.

Re:My experience: (1)

pete-classic (75983) | more than 4 years ago | (#32621120)

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: (1)

IdahoEv (195056) | more than 4 years ago | (#32621124)

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: (0)

Anonymous Coward | more than 4 years ago | (#32621190)

We're currently using Prawn, but, for my next Rails app, I want to take a look at PDFKit:

http://thinkrelevance.com/blog/2010/06/15/rethinking-pdf-creation-in-ruby.html

Re:My experience: (1)

jmactacular (1755734) | more than 4 years ago | (#32621374)

Using PDF has many advantages when it comes to printing. You don't have to worry about whether the browser has turned on/off the setting to print background colors/images. You don't have to worry about extra headers/footers that a browser prints by default. You also have more control over fonts. That being said, most people still try to print web pages, without having to open up PDF. So, I like to use the css media=print for special tweaks that are only for print. The question of which browser to use though is determined by your expected end user demographic. And depends on whether you have any influence over which browser they choose, i.e. a company intranet. In terms of compatibility, it'll probably never be perfect. But if you're willing to do what it takes to get the job done, any browser can handle complex web apps. Getting it to work flawlessly in more than one at the same time, is the challenge. =)

Re:My experience: (1)

pctainto (325762) | more than 4 years ago | (#32621428)

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.

Stop using the browser for print (5, Insightful)

Simmeh (1320813) | more than 4 years ago | (#32620818)

Export your data to XML or PDF on the fly and have something sensible print it.

Re:Stop using the browser for print (1)

Neil Hodges (960909) | more than 4 years ago | (#32620998)

XML, as in XHTML?

Re:Stop using the browser for print (2, Insightful)

Simmeh (1320813) | more than 4 years ago | (#32621078)

no, as in XML-FO which is designed for publishing.

Re:Stop using the browser for print (1)

darkain (749283) | more than 4 years ago | (#32621430)

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.

Forget them all! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32620820)

Write your own and open source it.

Chrome, PDF (5, Insightful)

amicusNYCL (1538833) | more than 4 years ago | (#32620826)

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! (2, Funny)

turtleAJ (910000) | more than 4 years ago | (#32620828)

All the way!

Civility abounds (0)

Just Some Guy (3352) | more than 4 years ago | (#32620830)

I welcome a calm, reasoned discussion of the topic's many nuances.

Re:Civility abounds (2, Funny)

Narcocide (102829) | more than 4 years ago | (#32620962)

How about this then? What fucking printing bug?

Re:Civility abounds (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#32621218)

Shut the fuck up, no-clue douchebag.

Printing from web apps? (0)

Anonymous Coward | more than 4 years ago | (#32620834)

Generate a pdf for the user to download and print instead.
Its the only reliable method.

Also, why are you asking Slashdot what browser to use? Do you expect to have any say in the browser your end users have?!

Why not fix the browser requirement (0)

Anonymous Coward | more than 4 years ago | (#32620844)

How complete is the system at this time? Has it been used in production or is it still in development. If so, how many hands have been involved and how old is the original work? You may have bit off more than you can chew unless you can customize your own browser and code to use only it and its descendants.

PDF? (0)

Anonymous Coward | more than 4 years ago | (#32620846)

If your application really needs to print something ill recommend you to create a pdf server side and offer it to the client.

you can transform your current html templates to pdf once they are filled with data with:

dompdf: http://www.digitaljunkies.ca/dompdf/

which uses tcpdf, aslo Free software: http://www.tcpdf.org/

or some commercial reporting tool, but pdf is the way to go.

you can even embed the pdfs inside the html, see http://blogs.adobe.com/pdfdevjunkie/2007/08/using_the_html_embed_tag_to_di.html

Writing to a specific browser... (5, Insightful)

John Hasler (414242) | more than 4 years ago | (#32620864)

...is a much more serious bug than any possible printing problem.

Re:Writing to a specific browser... (2)

Anonymous Psychopath (18031) | more than 4 years ago | (#32621358)

...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.

Use Flex and PDF for printing. (-1)

Anonymous Coward | more than 4 years ago | (#32620876)

I feel your pain.

I am having to maintain a web based system that was developed a couple of years ago and it's doing my head in.

The only time I have developed a web-based solution that behaved the same in all browsers, predictably, every time, was when I used Flex 3. This javascript/css/html bullshit is just a fucking huge hack.

Punch in the eyeball (5, Insightful)

EmperorOfCanada (1332175) | more than 4 years ago | (#32620878)

If you forced me to use Opera to use your system I would demand that they find a new developer. Or as a customer I would find a new system.

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 (1)

Traf-O-Data-Hater (858971) | more than 4 years ago | (#32621038)

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.

Re:Punch in the eyeball (1)

cosm (1072588) | more than 4 years ago | (#32621380)

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 (4, Interesting)

Qzukk (229616) | more than 4 years ago | (#32621420)

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. (1)

pwnies (1034518) | more than 4 years ago | (#32620882)

It sounds like the web-app you're using isn't coded well. Hate to put it that way, but if you're having this many problems with it, it's probably true. As for browsers to use - just switch until you find one that works. Try each of the rendering engines and browsers that use them (trident, webkit, gecko, presto, etc). Find one that works, use that.
Next time around though, write the app better. Export to PDF/PS if you need formatting to be absolutely preserved.

Define "printing problems" (1)

DragonHawk (21256) | more than 4 years ago | (#32620894)

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 just learn to use css (1)

Narcocide (102829) | more than 4 years ago | (#32621026)

Use a print stylesheet, swap body classes to mask unwanted rules from the main stylesheet, then set key sizes in percentages so that it has some adaptability to different page sizes. I've seen it done correctly as long as you can assume a specific installed font or something with identical glyph bounding box sizes. Seriously. What print bug does Firefox have that's not actually just expected behavior if you know CSS?

Or export PDF, PS, etc. (1)

betterunixthanunix (980855) | more than 4 years ago | (#32621112)

Or we can go with the simpler answer, exporting a format that will render and print correctly regardless of which browser (or browser version) or operating system is in use. Why waste time getting a stylesheet to work, when you could just render a PDF instead, especially considering the number of PDF authoring tools and libraries that exist?

Re:Or export PDF, PS, etc. (1)

Narcocide (102829) | more than 4 years ago | (#32621232)

Well, while I think that differing expertise levels in different areas can make "simpler" a somewhat subjective concept, I also think that anyone making a "complex web application" owes it to themselves to learn at least enough CSS to be able to tell the difference between expected behavior and an actual rendering bug, rather than just assuming because Firefox is rendering their code differently the only option is to switch rendering engines.

Re:or just learn to use css (2, Funny)

Dr Herbert West (1357769) | more than 4 years ago | (#32621398)

Sure... because CSS always formats uniformly across different browsers and platforms. And browser detection never fails or degrades over time.

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 (1)

Qzukk (229616) | more than 4 years ago | (#32621496)

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.)

Next Ask Slashdot... (1)

by (1706743) (1706744) | more than 4 years ago | (#32620910)

Best PDF Viewer For Printing Complex Documents?

i.e.6 (0)

Anonymous Coward | more than 4 years ago | (#32620924)

/ducks

mediatype:screen vs print (1)

MoFoQ (584566) | more than 4 years ago | (#32620948)

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 (2, Informative)

Zadaz (950521) | more than 4 years ago | (#32620950)

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 (1)

Layth (1090489) | more than 4 years ago | (#32621274)

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.

Off load printing to another application (1)

jaymz2k4 (790806) | more than 4 years ago | (#32620954)

As many have suggested look at outputting your data in a format that allows it to be used in another application. I typically allow for CSV or PDF output. There are libraries [google.com] out there to do that within your app. The path of least resistance is your friend. I have seen developers spend an age trying to replicate the functionality of excel for a web view when a CSV export would've been much more useful, cleaner and far easier to code.

When in doubt have something else handle it!

Not reinventing the wheel?! (1)

betterunixthanunix (980855) | more than 4 years ago | (#32621054)

Here I was, thinking that reinventing the wheel was a requisite part of developing a web app. Are you really trying to suggest that we leverage an existing and mature codebase for rendering and printing documents or processing data tables?

Now, if only more people thought this way.

Use css print alternate (0)

Anonymous Coward | more than 4 years ago | (#32620980)

You can use an alternate stylesheet for printing as opposed to mobile or screen. The browsers automatically select the print css and render accordingly when you print. You can use this to strip out things like navigation (which is hard to do on paper ;) ) that aren't relevant in that medium and optimize text styles so they are optimized for a nice printout.

This tends to work best if you've laid out the site using CSS instead of tables.

PDF (1, Interesting)

Anonymous Coward | more than 4 years ago | (#32620994)

If you're trying to print from the browser, you're doing it wrong:
http://thinkrelevance.com/blog/2010/06/15/rethinking-pdf-creation-in-ruby.html

Short answer: don't. (1)

TomXP411 (860000) | more than 4 years ago | (#32621008)

I wouldn't use the browser for printing. I would render the document to an RTF on the server, then hand it over to the client for printing.

Re:Short answer: don't. (1)

TomXP411 (860000) | more than 4 years ago | (#32621028)

Darnit, I didn't mean RTF. I meant PDF. :-) Although, RTF's work too, as long as a good word processor is installed.

One thing missing here (1)

Aexia (517457) | more than 4 years ago | (#32621018)

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 (1)

Anonymous Psychopath (18031) | more than 4 years ago | (#32621394)

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.

The "Best Browswer"... (1)

NotQuiteReal (608241) | more than 4 years ago | (#32621070)

The "Best Browswer" is the one your paying customers use. For better or worse.

Use PDF (1)

tibit (1762298) | more than 4 years ago | (#32621168)

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 (1)

micheas (231635) | more than 4 years ago | (#32621414)

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 (1)

saccade.com (771661) | more than 4 years ago | (#32621208)

If you want to do quick cross-browser testing, try Browser Lab. [adobe.com]

Re:Try BrowserLab (0)

Anonymous Coward | more than 4 years ago | (#32621296)

Their System Requirements [adobe.com] annoy me.

If you find Opera bug... (0)

Anonymous Coward | more than 4 years ago | (#32621248)

Be sure to report bugs to their Desktop Team [opera.com] , the devs there are crazy when it comes to releasing builds (seen a few weekend releases). From my experience, they were able to solve my issues within 2-3 builds (a work week, give or take), whereas my Firefox bug reports take months (not to mention my pet peeve - Aptana bugtracker).

They're currently preparing the next big version (10.60), so I believe they would be interested in fixing any important problem.

Better write for all browsers (1)

JThaddeus (531998) | more than 4 years ago | (#32621298)

You'd best cover IE, Firefox, and Safari at a minimum. I've been using the Google Web Toolkit (http://code.google.com/webtoolkit/) for the past 3 years and have been very happy with it.

A third option... (1)

dmgxmichael (1219692) | more than 4 years ago | (#32621344)

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. (5, Insightful)

poor_boi (548340) | more than 4 years ago | (#32621364)

You've got it backwards. You don't write a web application and then go around installing 9 different browsers at 20 different patch levels in a search to find one which finally doesn't break while using your app. Rather, you write an application and install 9 different browsers at 20 different patch levels to make sure none of them break while using your app. Fix the app, not the browser. And if the problem is intractable in the most popular versions of the most popular browsers, change your framework.

Render to PDF (1)

wiredlogic (135348) | more than 4 years ago | (#32621406)

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 (5, Interesting)

corsec67 (627446) | more than 4 years ago | (#32621436)

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)

third party standards (0)

Anonymous Coward | more than 4 years ago | (#32621508)

Use third party options for consistency.

For webapps: Flash or SilverLight (I'd include Java, but I've been burned too often with version upgrades causing bugs)

For printing: PDF

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>