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.
Related
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.
(Beginner to HTML)
I have made a Photoshop mock-up of the website I want to make, but the text I have used in the mock-up looks different when viewed in Firefox. The text is Arial font, size 18pt and regular weight, and I have implemented this into HTML code, but it looks different.
Is there a way to make the font look the same in HTML as it does in Photoshop?
Thanks in advance :)
The short answer is "no". Photoshop has a lot more font functionality than a web browser. It applies all kinds of smoothing algorithms, and you can control kerning, tracking and spacing much better.
Each browser and OS has a distinct rendering engine as well, so even if you could get it the same in one browser/OS combination, it would look different in another.
However, check out all the CSS properties for text to see if you can get something you're able to live with. If not, your best bet is to just make an image out of your text and add it to your page with good "alt" text and such.
I'm not sure what OS you're on, but Windows and Macintosh have different font systems.
This post by Joel Spolsky points out that the font rendering is based on philosophical differences.
Is that what you're seeing? Please post images so we can see what you're talking about.
Fonts are something you simply can't get right on the web. If you absolutely have to control the look of fonts, then you have to use images (and get beaten for it, rightly so). It's simply not possible to achieve pixel-perfect text display in HTML. This starts with differences in fonts the operating system has and ends with differences in browser layout engines.
There are two ways to do it:
Take an image of that font and use it in the layout.
Use a custom font creation tool like SIFR or FLIR. This is a tricky option b/c you need to own Adobe Flash and you need to have the distribution rights to the font (similar to books, music, etc.).
Basically, if you want to have it look exactly the same and still stay standards compliant, this is really almost impossible.
If you're looking for how to turn Adobe Photoshop mockups into HTML documents, you should check out the screencast series on CSS-tricks.com, run by Chris Coyier, a very talented designer (no it's not me :) ).
Another thing that you will have to understand is that it is the people with the Web browsers that ultimately control how your page will look. So no matter how much fiddling you do to get a website the way you want to see it, it will view differently on someone else's computer
If you need perfect, crystal clear font matches you can use flash... but that comes with a whole boatload of downsides.
I need a tool to compare the design of a website, I do not want to compare the HTML code only, but the output design.
Is this even possible? also is there any opensource program of this kind?
I have searched google, but I only get one candidate so far which is an HTML Match.
In modern webpages the appearance is controlled by various 'things': html code, css styles and images at least (also javascript in some pages). Simple text-based diff programs are not enough because their output can be irrelevant to the webpage appearance (i.e. cleaning up css can show many differences but the rendered webpage remains the same).
For simpler pages HTML Match mentioned above could do the job. If I have to compare the design of two "complex" pages (including layout, space, image and text changes) I would do a two-step approach:
Run a diff tool on the html sources to highlight the textual content differences. Then I would modify one of the pages to show the same content as the other (in order to make the next step more accurate and 'focused' to show 'real' layout changes). Of course it works only with very similar html.
Load the pages in the same web browser, get some screenshots from the rendered output at fixed positions and compare the images (i.e. with ImageMagick). It should show all visual differences in the rendered output.
It is not perfect but should work.
[UPDATE] HTML Match seems dead, see this answer for an alternative solution.
Solution: “compare web pages” tool. (“We've been doing it since 1999. It's free.”)
Example output (comparing pages for TP-Link USB hub model UH700 and UH720):
Under windows:
http://www.htmlmatch.com/
If you are using KDE, you can use Kompare or KDiff3.
However, if you want to view how your web page looks in different browsers in different operating systems, BrowserShots can used.
There are these online tools - that aren't brilliant:
http://www.w3.org/2007/10/htmldiff
http://www.aaronsw.com/2002/diff/
I like the look of daisydiff but have not used it in anger: http://code.google.com/p/daisydiff/
The keyword you're looking for is "diff".
A good program that can show you the differences between two files (html markup or other) would be ExamDiff for windows.
I'm working on one and i tell you it's hard and there is nothing on the market. Maybe Google and Bing have something inhouse. You can use some image comparison tools which identify rectangle regions of changed images. This is for example a part of all modern video compression but you have to do it for different regions of the webpage (the nav bar section, the main article, the region filtered by an ad-blocker etc.) as some of them may change and it's still considered the same content on the page.
As i said very complex problem with no exact solution.
The other is going the non visual way and just compare the resulting computed computer styles of each html element. You have to hack the browser to get access to the layout tree. There is also no official API or existing library/program/hack/patch for it.
You can make a visual comparison with Araxis Merge Pro by taking screen output with systems like BrowserStack, Cross Browser, PhantomJS
I'm trying to compile a guide for students used to publishing in print who are learning web design.
Some obvious things which web developers know but they don't:
You can't rotate graphics in HTML
All objects have to be rectangular, you can't have a circular DIV
Many typographical effects in their repertoire can't be achieved
Some things which are tricky are:
Can they have variable opacity? Well, yes and no.
Can they have rounded corners? Maybe.
Some things which aren't technical difficulties, but which are problems:
Image file sizes: I have a student who wants to have a different large graphic header on every page of their site; that's not technically a problem, but it will mean a visitor has to wait for a new graphic to load every time they navigate
Accessibility: "why not just make everything a graphic, to overcome the limitations of HTML?"
Please help me fill out my list and add any hints or tips for people making this transition.
web is not print
Layouts can be fluid.
elements don't have to be absolutely positioned
web pages need to be checked in several browsers for compatibility
avoid divitis; from experience people coming from print into this field do everything by brute force instead of trying to think of elegant solutions for optimization and semantics purposes
print is consumed visually - the web is consumed by people with visual impairments as well. Don't forget lynx users no matter how small the market share is :)
semantics is important, learn about them
thats all i can think of right now...
Coming from someone who has done both print design and web design (and done a decent job at both, I think), it seems like you're off to a good start. Other thoughts:
Darko Z mentioned this but I think it's worth stressing that browser incompatbilities must be recognized and dealt with. In the print industry there are standard formats like PDF which guarantee that things will come out in print the way they look in design; besides, many publishers will directly accept the native file formats of the most popular design programs, like Adobe InDesign, Quark XPress, even MS Word (for the cheapskates ;-P). The point being that print designers are used to a "set it and forget it" approach where they assume that once they design something a certain way, it will stay designed. The fact that there are different web browsers which render the same web pages slightly differently is likely going to be a major pain in the butt for people used to the print world.
Addendum to the above: fonts. You can't use (or at least can't rely on) uncommon fonts in web design, for obvious reasons.
Screen real estate has to be used effectively because there's a limited amount of it. And I mean really limited - no matter how hard you try, you can't write HTML that will make someone's monitor expand 5 inches or put another screen on the back ;-) It's not like in print where people can peek back and forth between different pages of a book. Reading web pages is kind of like looking at parchment through binoculars; you have to design the pages with that limited field of view in mind.
Web page designs are dynamic and transient; they stay up for a while, they get boring, they get recycled/replaced with new designs. So you're not stuck with mistakes. But it also means you need to design with future changes in mind, e.g. by using CSS so you can change the look of whole classes of elements easily. There is some use of styles in print design but nowhere near as much as online.
Fonts and Text
You are limited to a small subset of
fonts
Fonts are viewed at different sizes
There is a readability limit for how
wide paragraphs should stretch (in a
fluid layout)
Write for readers of all types - Some
will skim, others will read in detail
Images
Sites are viewed at different
resolutions and screen sizes - Design accordingly
To achieve transparent backgrounds in
IE6, use PNG8 with alpha (IE6 doesn't
support varying levels of
transparency, it's either 100%
transparent or it's opaque)
Use CSS sprites
Images should not be used in place most of text
The img tag should be used for images
with semantic value and all layout
images should be CSS images
Every img tag needs to have the alt
attribute to validate
(X)HTML and CSS
Browser rendering varies greatly
Validate CSS and (X)HTML for a
greater probability that the design
will be cross-browser friendly
Don't use CSS hacks
Use the proper semantic markup
Pages should be able to work without
JavaScript enabled
Read Yahoo's guide for
performance and use YSlow
Dreamweaver's design mode doesn't
reflect how a page will appear in
real browsers
General Design
Simpler is often better in terms of
usability, accessibility, design, and
download size
Lists of greater than five or six
items should be broken up visually
Consistency is important - Don't
change your navigation, etc without
an extremely good reason
When choosing colors, keep those with
color-blindness in mind. This will
affect how you choose to convey
meaning by color.
Place the most important information
above the fold (the part of the
screen that shows without scrolling)
The web is interactive. This
drastically affects how you consume
and display information. You can hide and subsequently display information using tabs, accordion, and similar methods.
Think in terms of primary and
secondary calls of action. What do
you want the user to do? Where do you
want them to go next?
Some broad points:
1. Print is static, the web is interactive.
The essence of a print project is a fixed point in time, an idea captured on paper or some other substrate. Web projects are moving, changing experiences that represent both the ideas of their creators and their users.
2. Everything is uncertain.
You mention typography in your answer, it's probably worth broadening that to cover all aspects of appearance. The variety of operating systems and hardware available mean that its hard to determine how all your audience will experience your final design. Whilst some things must be compatible across all browsers, sometimes it is not worth the time and effort needed to make something pixel perfect in all systems.
3. Learn about programming.
Unless you've an aptitude for it, you don't need to learn how to program for the web. But it would still be a big help to gain some familiarity with web programming, as if you can't code, you'll need to work closely with someone who can and you need to be able to communicate effectively with them.
4. Create working prototypes
When something is static, it can be designed using a static format. To design something interactive like a website, you should be making use of moving prototypes that represent the kind of behaviour the final design will have. You can use paper to do this, or more sophisticated mockups using xhtml, css and javascript, or a dedicated prototyping program.
The user controls how they want to see content on the web, not you. Your design will not look the same to all people because some people may make it different on purpose.
Screens can be arbitrarily large or small
The web is interactive: usability trumps pretty-lookingness
Your page will be read by machines: make sure the data is easy to get at by scripts that can't read images / large blobs of text (aka "be semantic")
Remember to save your jpg files in RGB format not CMYK format. I regularly get sent jpgs that won't display on a web-site and every time it's because it's been saved in the wrong format from Photoshop.
This will become less of a problem as browsers support more image formats, but considering that 20%+ of users are still on IE6 for the sites we develop this will take a while to go away.
A lot of these are good rules of thumb for print designers who want to learn how to actually markup HTML and write CSS. But as a Web developer in the past, I'd frequently just take a designer's template and write the HTML and CSS for them. Whether or not that task was simple or difficult depended on the designer's awareness of the capabilities of CSS.
There was one pain point in particular that kept coming up. So for print designers moving to the web, the absolute number one rule to remember is:
Don't design any element to have an explicit, pixel-perfect height. You can restrict the width all you want, but changing fonts, preferred font sizes, and different text strings being pulled from the database on different pages means that text needs to be able to flow vertically without generating hideous, hard-to-use overflow scrollbars.
Designers who remember this can usually conjure up designs that are easy to cut up and integrate in a mostly semantic manner. Designers who forget this sometimes end up creating designs that have to be shoehorned into a 3 inch by 3 inch box, and that's when I reach for the vodka.
A given color or font will render differently in different browsers.
Especially when one browser is on Windows and the other is on Mac or Linux, etc.
I wrote a blog post about this a while ago - http://aloestudios.com/2008/08/dear-print-designer-doing-web-design/
So did my friend Mark - http://www.visual28.com/articles/tips-for-better-web-design
Jeffery Zeldman's book Taking Your Talent to the Web is specifically targeted to the question you have asked. It's been out for a few years...not sure if there's a 2nd or 3rd edition. Check it out.
My main advise is that you need to recognize that while you have dot precision in print applications, most of the time in web design your focus is to design and code a site that will accomplish your content and layout goals for any number of platforms, resolutions and color depths. Color depth has become less important than it was in the past.
In my Delphi program I want to display some information generated by the application. Nothing fancy, just 2 columns of text with parts of words color-coded.
I think I basically have two options:
HTML in a TWebbrowser
RTF in a TRichEdit.
HTML is more standard, but seems to load slower, and I had to deal with The Annoying Click Sound.
Is RTF still a good alternative these days?
Note: The documents will be discarded after viewing.
I would vote for HTML.
I think it is more future oriented. The speed would not concern me.
The question of HTML or RTF may be irrelevant. If they are just used for display purposes, then the file format doesn't matter. It's really just an internal representation. (Are any files even being saved to disk?) I think the question to ask is which one solves the problem with the least amount of work.
I would be slightly concerned that the browser control is changing all the time. I doubt the richedit control will change much. I would lean towards the richedit control because I think there is less that could go wrong with it. But it's probably not a big deal either way.
Have you considered doing an ownerdraw TListView?
I'd also use HTML. Besides, you just got an answer for the clicking sound in TWebBrowser.
If you'd rather not use TWebBrowser, take a look at Dave Baldwin's free HTML Display Components.
I would vote for HTML, too.
We started an app a while ago...
We wanted to
display some information generated by the application. Nothing fancy, just...
(do you hear the bells ring???)
Then we wanted to display more information and style it even more....
...someone decided, that RTF isn't enough anymore, but for backwards compatibility we moved on to MS Word over OLE-Server. That was the end of talking about performance anymore.
I think if we would have done that in HTML it would be much faster now.
RTF is much easier to deal with, as the TRichEdit control is part of every single Windows installation, and has much less overhead than TWebBrowser (which is basically embedding an ActiveX version of Internet Explorer into your app).
TRichEdit is also much easier to use to programmatically add text and formatting. Using the SelStart and SelLength, along with the text Attributes, makes adding bolding and italics, setting different fonts, etc. simple. And, as Re0sless said, TRichEdit can easily be printed while TWebBrowser makes it more complicated to do so.
I would vote RTF as I dont like the fact TWebBrowser uses Internet explorer, as we have had trouble with this in the past on tightly locked down computers.
Also TRichEdit has a print method build in, where as you have to do all sorts of messing about to get the TWebBrowser to print.
Nobody seems to have mentioned a reporting component yet. Yes, it is overkill right now, but if you use it anyway (and maybe you already have got some reporting to do in your app, so the component is already included) you can just display the preview and allow to print / export to pdf later, if it makes any sense. Also if you later decide that you want to have a fancier display there is nothing holding you back.
If both HTML and RTF won't satisfy your need, you could also use an open source text/edit component that supports coloring words or create your own edit component based on a Delphi component.
Another alternative to the HTML browser is the "Embedded Web Browser" components which I used a few projects for displaying html documents to the user. You have complete control over the embedded browser, and I don't recall any clicks when a page is loaded.
I vote for HTML also
RTF is good only for its editor, else then you'd better go standard.
RTF offers some useful text editing options like horizontal tabulator which are not available in HTML. Automatic hyperlink detection is also a nice extra. But I think I would prefer HTML, if these features are not required.
I vote for HTML.
Easier to generate programmatically.
Widely supported.
Since you don't need WYSIWYG capabilities I think HTML advantages trump RTF. Moreover, should the need to export generated data for further, WP-like editing arise, remember that major word processor can open and convert HTML files.
Use HTML, but with 'Delphi Wrapper for Chromium Embedded' by Henri Gourvest , Chromium embedded uses the core that powers Google Chrome.
Don't use TWebBrowser, I'm suffering from all programs that use IE's web control - the font is too small on my 22' monitor with a 1920x1080 resolution, I use Windows 7 and my system's DPI is 150% (XP mode), I tried everything to tweak trying to fix that, no luck...