I'm looking for a web based word processor. I'd like something that prints exactly what the user sees on the screen.
It's for an internal app so I don't need something available only through the Internet.
You will find it very very hard to have a consistent experience on screen and on users's computers. If you can control the environment to a point where you can force all users to use the same browser on the same OS you'll be fine, otherwise you should try a more hybrid approach. Something that can have slight print variations but also works fine.
Google Docs uses a verry interesting method for presenting the info to the user before printing. They convert your page to a PDF, prior to printing and there you can see exactly what will be printed or not. If you're good to go, shot. If not you can come back to the textarea and keep iterating.
Related
I know there are several tools available to find unused CSS on a static web page. But in most real world scenarios I encounter, a lot of the CSS is used after some or the other interaction on the page, maybe a new modal opening up or an options popup etc.
In such scenarios, what would you suggest? How do I keep a tab on my ever-growing render blocking CSS?
The only way I guess one could do that is by running regular unused-css-detector type tools in conjunction with Selenium - test known interactions and see whats left unused. But a big assumption here is that I'd need to know all interactions on my page which could use new CSS. Is there a way to achieve my goal without making this assumption?
In an ideal world, I'd be able to post-back all CSS used by a visitor's browser on my page to my server. Then I'd collect data over a month, aggregate, and get a pretty accurate idea about actual unused CSS.
Any good ideas?
I am the author of a tool that is aiming at doing what you are describing. Everywhere I worked, the CSS is this "append-only" thing that is too risky, too time-consuming to clean up. And even when you try, the ROI is so low that it not worth it.
So I am working on a tool that is very similar to what you are describing. The goal is to bring confidence on what can be removed, and to actually do it automatically by submitting pull requests.
A snippet of JavaScript is running in the browser and sends reports of what is being used to a server. Once enough data is accumulated to build some "confidence score", it can create Pull Request automatically to remove selectors that are actually not used.
It is still very early stage, but you are welcome to try it and give some feedback about it.
https://www.bleachcss.com/
I've read quite some post about the angularjs html5Mode including this one and I'm still puzzled:
What is it good for? I can see that I can use http://example.com/home instead of http://example.com/#/home, but the two chars saved are not worth mentioning, are they?
How is this related to HTML5?
The answers links to a page showing how to configure a server. It seems like the purpose of this rewriting to make the server return always the same page, no matter what the URL looks like. But doesn't it read to needlessly increased traffic?
Update after Peter Lyons's answer
I started to react in a comment, but it grew too long. His long and valuable answer raises some more questions of mine.
option of rendering the actual "/home"
Yes, but that means a lot of work.
crazy escaped fragment hacks
Yes, but this hack is easy to implement (I did it just a few hours ago). I actually don't know what I should do for in case of the html5mode (as I haven't finished reading this seo article yet.
Here's a demo
It works neither in my Chromium 25 nor in my Firefox 20. Sure, they're both ancient, but everything else I needed works in both of them.
Nope, it's the opposite. The server ONLY gets a full page request when the user first clicks
But the same holds for the hashbang, too. Moreover, a user following an external link to http://example.com/#!/home and then another link to http://example.com/#!/foreign will be always served the same page via the same URL, while in the html5mode they'll be served the same page (unless the burdensome optimization you mentioned gets done) via a different URL (which means it has to be loaded again).
but the two chars saved are not worth mentioning, are they?
Many people consider the URL without the hash considerably more "pretty" or "user friendly". Also, a very big difference is when you browse to a URL with a hash (a "fragment"), the browser does NOT include the fragment in it's request to the server, which means the server has a lot less information available to deliver the right content immediately. As compared to a regular URL without any fragment, where the full path "/home" IS including in the HTTP GET request to the server, thus the server has the option of rendering the actual "/home" content directly instead of sending the generic "index.html" content and waiting for javascript on the browser to update it once it loads and sees the fragment is "#home".
HTML5 mode is also better suited for search engine optimization without any crazy escaped fragment hacks. My guess is this is probably the largest contributing factor to the push for HTML5 mode.
How is this related to HTML5?
HTML5 introduced the necessary javascript APIs to change the browser's location bar URL without reloading the page and without just using the fragment portion of the URL. Here's a demo
It seems like the purpose of this rewriting to make the server return always the same page, no matter what the URL looks like. But doesn't it read to needlessly increased traffic?
Nope, it's the opposite. The server ONLY gets a full page request when the user first clicks a link onto the site OR does a manual browser reload. Otherwise, the user can navigate around the app clicking like mad and in some cases the server will see ZERO traffic from that. More commonly, each click will make at least one AJAX request to an API to get JSON data, but overall the approach serves to reduce browser<->server traffic. If you see an app responding instantly to clicks and the URL is changing, you have HTML5 to thank for that, as compared to a traditional app, where every click includes a certain minimum latency, a flicker as the full page reloads, input forms losing focus, etc.
It works neither in my Chromium 25 nor in my Firefox 20. Sure, they're both ancient, but everything else I needed works in both of them.
A good implementation will use HTML5 when available and fall back to fragments otherwise, but work fine in any browser. But in any case, the web is a moving target. At one point, everything was full page loads. Then there was AJAX and single page apps with fragments. Now HTML5 can do single page apps with fragmentless URLs. These are not overwhelmingly different approaches.
My feeling from this back and forth is like you want someone to declare for you one of these is canonically more appropriate than the other, and it's just not like that. It depends on the app, the users, their devices, etc. Twitter was all about fragments for a good long while and then they realized their mobile users were seeing too much latency and "time to first tweet" was too long, so they went back to server-side rendering of HTML with real data in it.
To your other point about rendering on the server being "a lot of work", it's true but some consider it the "holy grail" of web app development. Look at what airbnb has done with their
rendr framework. See also Derby JS. My point being, if you decide you want rendering in both the browser and the server, you pick a framework that offers that. Not that you have a lot of options to choose from at the moment, granted, but I wouldn't advise hacking together your own.
I have a report I need to print out in an application I'm usually doing maintenance for. My question, which interests me beyond the scope of this task is, what are the ways to format an HTML page for printing? What are the pros and cons of each?
Note that the page is meant only to be printed. I'm not asking about an HTML page that looks ok also when printed.
Generally speaking, I know I can either rely heavily on <table>s or on <div>s, but I don't know which way to go.
I would also appreciate some resources to get me started, or to help with known problems, in any method you suggest.
Thanks,
Asaf
As you can certainly see, printing and web presentation are two different creatures. The main issue is the bounds of the printed page, which does not exist in a web page. Even if you think you have a page laid out in a manner that will fit a printed page, then you need to deal with the fact that the font you are using may not work or scale correctly on the user's printer.
I know of three ways to deal with this issue:
Use fixed-sized fonts (like Courier), limit yourself to an 80 column width, and only use font characters: meaning use something like asterisks for borders, etc. This is VERY old school - your reports look simple and old and plain. But, they will always print they way you intended.
Convert your report to an image. Images can be made to confirm to a specific size which can fit on a page. However, you can still have issues due to printer margin settings.
Let another application do the work for you. What I mean by this is put your report into a PDF or a spreadsheet. Both PHP and Perl have easy to use modules for creating a PDF - with no licensing needed. Perl has a fantastic spreadsheet module. This route takes a little learning up front, but frees you from having to be an expert on printing (which can be a real pain).
In case you DO want to have a page that also looks good when viewed in a browser, consider multiple stylesheets for different medias.
One business goal requires that I make a form on screen that's pixel-perfect. If a user prints this form, it will exactly match the US Government Printing Office version of the form; the printer will produce a (reasonably) scannable copy of this document. The previous solution is PDF, which will only work to a certain point for us.
I'm leaning towards HTML/CSS, and would like suggestions on tools to assist that.
For tools, PixelPerfect in Firefox seems a good start. The target platform for this is (drum roll) IE6, if it helps. The document looks like this.
If HTML/CSS is a complete no-go, Adobe Flex is my next choice.
If pixel perfect printing is the goal, and not even PDF will get you there, you can pretty much give up straight away on printing from the browser. There are waaaay too many variables when rendering on the client side: from different browsers (IE6? Good luck!) to different fonts, to user settings, to A4 vs Letter size paper.
Could I ask why PDF doesn't suit?
I agree that pixel-perfect layouts are very, very hard to achieve with html/css, particularly with forms. However, I think pdfs can recieve input from external web forms, or have textfields that when filled out will print.
Flex outputting to pdf would be a good idea, but I don't think using flex as an rendering engine will help too much with this.
Another option would be to make the pdf and use a server-side langage to customize it with fields from a prior webform, and output the result. (Can easily be done with ruby/django/php, there are some good pdf libraries out there.)
First, abandon pixels. What you're looking for is a print stylesheet, with everything specified using physical units (cm/inches), font size in pt, etc. What is displayed on the screen, in what font size, and whether it is pixel-perfect or not doesn't seem relevant to your requirement of producing a scannable copy.
The question is now, is IE6 support for physical units and print stylesheets complete enough for that? Given my experience with making print stylesheets for clients, where IE would simply crash during the print process if you looked at it wrong, I'd say not too likely -- not with the complexity of the forms you're dealing with.
If you're worried about the renderer (IE, Acrobat, etc.) screwing up, you could always render the form on the server, and just serve an image to the user.
Dean, check out Prince. Bert Bos and Håkon Wium Lie used it for production of their book on CSS. They explain a bit about it in an A List Apart article.
The company I work for we have a CBT system we have developed. We have to go through and create books out of the content that is in our system, I have developed a program that goes through and downloads all of the content out of our system and creates a offline version of the different training modules.
I created a program that creates PDF documents using the offline version of the CBT. It works by using Websites Screenshot to create a screen shot of the different pages and then using iTextSharp it creates a PDF Document from those images.
It seams to be a memory hug and painfully slow. There are 40 CBT Modules that it needs to turn into books. Even though I take every step to clear the memory after each time it creates a book. After about 2 books it crashes because there is no memory left.
Is there a better way to do this instead of having to take a screen shot of the pages that will yield the same look of the web page inside the pdf document?
I have searched and demoed and found that ABCPdf from WebSuperGoo is the best product for .NET. It is the most accurate and doesn't require a printer driver. It uses IE as the rendering engine, so it looks almost exactly like what you get in IE.
PrinceXML is commercial software that generates pdf from websites.
I've used PDFSharp in the past and have had good success in generating PDF's.
It's open source as well, so in the event of troubles like you've mentioned, you're able to hunt and peck to increase performance.
If you control the source it is probably not too difficult to generate pdf directly instead of through a screenshot.
Did you try unloading the dll?
There are also different ways of getting screenshots:
http://mashable.com/2007/08/24/web-screenshots/