How can I detect the number of printing page will be on a form using JavaScript?
I need to get the number of pages that a form would be so I can stick a watermark per page to be printed.
Thanks.
I'd recommend that you read this article by A List Apart
#page front-matter :left {
#bottom-left {
content: counter(page, lower-roman);
}
}
(this uses CSS3)
I don't think that can be done (except, as marcgg points out, with CSS3, but that is not widely enough in use yet).
You could give the browser some pointers by inserting elements with the page-break-after or page-break-before attribute, but that will not give you total certainty about what way your pages get printed in.
Depending on your layout, you may be able to work something out by placing an absolutely positioned image in relation to an element that has page-break-before: always. I've never tried that, though, and you would have to play around with it to see whether it's any good.
Background images are obviously not an option, as they are excluded from printing by default in all browsers I know.
I think if you want to get reliable watermarks, you will have to resort to generating PDF files, for example using the PHP-Based fpdf library.
Considering that even somewhat standard paper size differ (letter vs. A4), this is not really feasible. I usually generate a PDF when I need this kind of control.
AFAIK, it's just not possible. There's no way plain JavaScript can interact with your printer to determine settings, page numbers, or anything, without an ActiveX control or other plug-in.
You can, in some browsers, use CSS to specify where pages will break and keep track of page numbers that way, but you have to rely on the users not to zoom the page or increase the text size of the page before they print.
Related
I'm looking to control how something appears when printed from the browser to a 2.4"x4" label.
Currently, when I use a word processing application like Pages (Apple's version of Microsoft Word), I can set my document size to 2.4" x 4" and hit print and I know all of the content will fit on the label. I'm trying to achieve the same thing but in the browser.
I don't know for sure, but I'm thinking when I print from the browser currently it is including a lot of the white space, and trying to scale it all to fit on the label, which distorts the content.
I'm fairly new to front end web development, so I'm looking for some guidance on how to approach defining a printable area. I'd rather it all happen inside the browser, but I considered maybe having the site generate a PDF of the correct dimensions as I think that'll handle printing similarly to Pages.
Hope this makes sense!
While there are styling capabilities that cater to paged formatting, the web is built around continuous (paged-less) documents. Because of this, paged formatting is troublesome. For example, specifying the document page dimensions from the document isn't something you can do. Instead, the printer dialog provides a choice of page sizes and the rendering engine tries to fit your content into pages of that size.
CSS has a module for paged media which includes: page-break-after, page-break-before, and page-break-inside for telling the engine how block elements should break across pages; #page sections for specifying CSS that applies only to paged environments; and :blank, :first, :left, and :right psuedo-elements for creating rules tied to certain pages.
This question already has answers here:
Preventing a visitor from saving an image from my site
(15 answers)
Closed 8 years ago.
I have a website where I display digital proofs for clients of professional photographers. I would like to include an option of 'zooming' into the full resolution version of the image, but it is absolutely imperative that it be practically impossible for the end user to reconstruct and save/print the image.
Obviously simply disabling right clicking is out, as the user could simply dig up the image in the cache. Breaking the image into tiles, then reconstructing them via javascript has merit; the user could still dig up the tiles and put them together in Photoshop, but is that practical for them? That's up for debate. I was also wandering today if the image couldn't be read, sent as a character string of pixel color values, and then constructed on the client side using an absolutely positioned element for each pixel.
But my potential solutions seem to be getting more and more ridiculously convoluted. And I'd like something that's been tested and shown to be scalable. I can't possibly be the first to deal with this problem. Is there something else out there that I don't know about? What is the standard, accepted way to do this?
As an aside, I am aware that I will want to make the image data unavailable to external http requests. I would plan to have ColdFusion read the image file on demand and stream it to the client.
Thanks!
No matter what you do, someone could always screen capture the page. Keep a watermark on the full resolution image.
With 100% reliability, no. For an image to be displayed, it has to be downloaded onto the client's browser, and therefore CAN be retrieved.
You can make it harder for them to extract the image through various techniques, but none of them make it impossible - if nothing else, they can always just make a screen capture:
slice/dice the image into multiple pices and use table-based layouts to make it appear as a single image
javascript right-click disablers
various cache headers to try and prevent client-side cacheing
CSS overlays to try and prevent right-click->save as on the image itself
display in a Flash/Java app
etc... etc...
None are 100% reliable, and are all trivial to bypass by a determined (and even slightly knowledgeable) user.
You can't, unless you sell specific hardware, even then people can put a camera in front screen and take pictures
You can water mark your images
You can actively sue who ever steals your pictures (that is in reference to how others solve this).
Nicholas,
As you pointed, there is no protection against Print Screen.
I would suggest you to implement the media protection of sites like Image Bank (http://www.gettyimages.com), but is mostly based in NOT displaying full resolution images and heavy watermarking ...
I don't think there is a practical solution to your problem (if any).
Good luck!
I am going to have a lot of images and trying to find the most efficient way of storing these images to keep the page snappy.
So far I have thought of just the two ways: load with javascript eg picture = new Image(); picture.src = "file.jpg"; and append / remove to the page as necessary, or load into <img> and set display:none.
Are there other options? what is considered the best way to do this?
The best way for a photo gallery (if thats what you are building) is usually to have several sizes of the images, at least two:
a smallish size that is highly compressed and thus have a small footprint: this is the image you load into grids and display in a page where there are multiple images
a larger image with lower compression and higher image quality - this is the one you show when people want to see details.
Since people most often come to the detailed image from a page where the small/fast loading version has already been shown, and thus is already in the browsers cache, you do a little trick and have instant photos, without preloading anything.
It goes like this:
On the details page you show the highly compressed small image in an image tag that has the dimension of the larger detailed version. You then load the larger detailed version in the background using new Image() with an onload event attached that changes the source of the image tag with the small compressed version to the large detailed version.
It looks great, works fast and users will love you ;)
PS: the best way to store images is the browsers cache, not js or the DOM, so if you truly wish to preload images, which is generally a bad practice (tho it can be necessary sometimes), make the browser fetch them for you in the background by including a css file that references them in styles that aren't applied to visual areas of your site.
I'm not sure about "efficient", but the most logical way would be not use the JavaScript to load an image (useless if you have JavaScript disabled) or to set the image as hidden via the display property (likewise, and the browser will probably just load the image anyway).
As such, a sensible suggestion would be to use boring old paging and display 'n' images per page. However, to bring this up to date, you could use "lazy" (a.k.a. "deferred") loading and load additional page content via Ajax as the user scrolls. However, it's key that this gracefully degrades into the standard "paged" behaviour if JavaScript is disabled, etc.
The perfect example of this in operation is Google's image search, and if you search here on StackOverflow you see a discussion of possible implementations, etc.
It's better to use javascript the way that you have it and then add it to the DOM as you need, as opposed to first adding it to the to the DOM and then hiding it because DOM manipulation is much slower and you may not use some images
I am using Large fonts in my website at a few places and they don't appear anti-aliased or smooth... I was wondering if their is any way to show large anti-aliased fonts for browsers on windows OS which has anti-aliasing switched off as default... Similar to something they have on this website here
You can't control system anti-alias in CSS.
For that, you would have to use Flash text replacement, like sIFR (they are using h2swf)
If the user's OS or browser does not have anti-alias switched on, there's nothing you can do to force either to use it. You can use other rendering platforms like Flash, or using CCS to replace text with images, to allow fonts to be displayed with anti-aliasing, but it does seem like a kludge for something as simple as rendering text. Technologies like Flash will also alienate certain audiences, either whose devices have no support for them or they simply opt out of using them.
If your user does not have AA enabled, arguably they are displaying a preference or simply don't care about the particulars of how the font is rendered. At the end of the day, you simply cannot directly control the client your users will use to consume your website. On the web you will always be at the mercy of the client application. The best you can do is present it clearly and in such a way that it should be easy for users to get the best experience they can achieve with their client.
Don't lose any sleep over whether your pixels are slightly less pretty on one client.
Cufon is an alternative to sIFR. See comparison here:
http://net.tutsplus.com/tutorials/html-css-techniques/six-ways-to-improve-your-web-typography/
Good news : in IE9 (released 3/14/11) they seem to put much larger text as anti aliased by default. I have hardware acceleration disabled - so it probably has this effect for all users.
Warning: this is an exercise in futility but....
I did notice that the text-shadow css property seems to force anti aliasing in some browsers. Unfortunately I think only Chrome at this time...
Here's a sample...
(each heading is shown first normally - and then with a text shadow).
Best viewed in Chrome!
What is the "best practice" (accessibility/usability-wise) for resizing text with Javascript?
My current solution is that for when the user clicks the resize link it adds an extra class to the body tag.
It also sets a cookie and then when the page is loaded - onLoad() - it reads the cookie and reapplys the body class tag again if needs be.
The only thing not ideal is that it loads then applys - the previous solution was to edit the CSS file before the page loaded but that threw up security warnings if the CSS file was in a different directory.
So, essentially is my solution reasonable or is there a better way?
Adam
What is the "best practice"
(accessibility/usability-wise) for
resizing text with Javascript?
Best practise is "Don't".
Specify the font size in relative units and let the native browser controls change it if the user wishes.
Attempts to duplicate this functionality rarely give the font sizes that users need (and usually end up offering a choice atomic, microscopic and tiny). Yes, some users need 72pt text (or larger).
The built in browser controls work on most, if not all, sites. You don't need to use up canvas real estate duplicating them.
Your solution sounds fine, with one addition: you can read the cookie as the page loads and add the class to the body element while the markup is generated. Most server-side languages support this: PHP, JSP, RoR etc.
Other than that, you have a solid solution.
Adding a CSS style to HTML via JavaScript
I think your suggestion is an excellent way of doing it.
It means you have the flexibility of being able to add the CSS class to any sub element rather than the body so that you can change the text size of a specific element if you so desire.
Reading the cookie on page load
To get around the issue you describe I would look for the cookie in your server side language (php/asp/ruby etc) and display the content as specified by the cookie on page load.
In PHP your CSS class definition may look like this:
echo '<div class=\"'.($_COOKIE['text_size']!='' ? $_COOKIE['text_size'] : 'normal'). '\">';
What is the "best practice" (accessibility/usability-wise) for resizing text with Javascript?
"Web Accessibility Gone Wild" sums it up quite nicely imho:
If your default font size may be too small for site visitors, then make it an adequate size.
and,
All browsers allow the sizing or scaling of the page content - why duplicate this browser functionality?
Also, Care With Font Size:
The problem here is a basic usability and accessibility issue: a good design should look good without requiring the user to enlarge or reduce the text size.
However, if you have a valid reason - feel free to ignore this.