![]() |
Applet printing
I finally managed to produce an applet, and put it on my page
(using the <applet> tag). I tried to make it look nice, with the same background colour as the page itself. It looks just like the other pictures on the page, the only difference being that it moves when you press "run" (http://www.jw-stumpel.nl/bounce.html, bottom of the page). However, when I print (or print-preview) the page, Firefox (on Linux and Windows) just shows a blank area where the applet should be. IE7 prints the applet area correctly. Does anyone know if this is normal behaviour? Should this be considered a bug? Is there some trick (perhaps by changing something in the applet itself, om some trick in print css) to make FF print applets? Google did not get me very far with this. Regards, Jan |
Re: Applet printing
In article <472af49a$0$13746$ba620dc5@text.nova.planet.nl>,
JWS <jws@my.home> wrote: > I finally managed to produce an applet, and put it on my page > (using the <applet> tag). I tried to make it look nice, with the > same background colour as the page itself. It looks just like the > other pictures on the page, the only difference being that it > moves when you press "run" (http://www.jw-stumpel.nl/bounce.html, > bottom of the page). > > However, when I print (or print-preview) the page, Firefox (on > Linux and Windows) just shows a blank area where the applet should > be. IE7 prints the applet area correctly. > > Does anyone know if this is normal behaviour? Should this be > considered a bug? Is there some trick (perhaps by changing > something in the applet itself, om some trick in print css) to > make FF print applets? Google did not get me very far with this. > > Regards, Jan Just a little thing, you should reconsider your line-height: 120%; Best to leave it out completely, or consider using a ratio: line-height: 1.2; if you must have it in. The immediate effect of *your value* is to make the main heading at the top collide when user font-size is upped for comfort and it runs to 2 lines. Perhaps you will need more expert help with Java about why the radio buttons are too crowded together making the text disappear as in the 6 in the 16 and the 0 in the 50 for choice of Nmasses. -- dorayme |
Re: Applet printing
dorayme wrote:
> Just a little thing, you should reconsider your > > line-height: 120%; > > Best to leave it out completely, or consider using a ratio: > > line-height: 1.2; if you must have it in. I thought I had that fixed already by specifying some other line-height for h1, but apparently I hadn't. Thanks for pointing it out. Anyway I now followed your suggestion of changing 120% to 1.2 (without doing anything special with h1). To my amazement this made a difference; the line spacing inside the h1 (if it is longer than one line) is now correct. It doesn't change anything in the rest of the page. I thought (from the CSS specs) that 1.2 and 120% were just the same. > Perhaps you will need more expert help with Java about why the > radio buttons are too crowded together making the text disappear > as in the 6 in the 16 and the 0 in the 50 for choice of Nmasses. This does not happen in any of the computers (Windows and Linux only) or browsers that I tested it with. The distances between the buttons are (must be in this case) fixed in pixels, so it seems that your system has a bigger default font size than the systems I used. No particular font was specified; I assumed (apparently wrongly) that the java default font is always the same. BTW Are the texts "Nmasses" and "Spring display" also too big? I mean, do they run into the buttons on the right? They are "text" fonts which may be different from "UI" fonts. Regards, Jan |
Re: Applet printing
JWS wrote:
> I finally managed to produce an applet, and put it on my page > (using the <applet> tag). I tried to make it look nice, with the > same background colour as the page itself. It looks just like the > other pictures on the page, the only difference being that it > moves when you press "run" (http://www.jw-stumpel.nl/bounce.html, > bottom of the page). > > However, when I print (or print-preview) the page, Firefox (on > Linux and Windows) just shows a blank area where the applet should > be. IE7 prints the applet area correctly. Most Linuxes don't come with browsers' Java installed. Are you sure it is installed? -- easy enough to do if it isn't. This is a reason you might think about whether an applet will be usable to all your visitors. I stopped using them years ago. > > Does anyone know if this is normal behaviour? Should this be > considered a bug? Is there some trick (perhaps by changing > something in the applet itself, om some trick in print css) to > make FF print applets? Google did not get me very far with this. > > Regards, Jan |
Re: Applet printing
mbstevens wrote:
> Most Linuxes don't come with browsers' Java installed. > Are you sure it is installed? -- easy enough to do if it isn't. I am pretty sure: -- I installed Java 6 (a.k.a. 1.6) on my Linux system. -- I actually wrote the applet myself (on my system). -- It runs perfectly well on my system. But it does not print from Firefox on Linux (it does not print from Firefox when I boot the computer into Windows, either; so far it only prints from IE7 on Windows XP). > This is a reason you might think about whether an applet will > be usable to all your visitors. I stopped using them years ago. Yes, from Googling I got the impression that there is a general dislike of Java applets nowadays, among Web page creators. I do not quite understand why. Could you elaborate? What alternatives do you use for putting interactive programs on the Web? I am just a Java newbie (what you could call a "very very late adopter") but I was pretty impressed that my applet (which animates fairly complicated mathematical things) asks nothing more from the server than to serve up one file, of only 6003 bytes -- less than even a small .png, .gif, or .jpg picture, for instance. Regards, Jan |
Re: Applet printing
JWS wrote:
> mbstevens wrote: > >> Most Linuxes don't come with browsers' Java installed. >> Are you sure it is installed? -- easy enough to do if it isn't. > > I am pretty sure: > > -- I installed Java 6 (a.k.a. 1.6) on my Linux system. You also have to make sure that the browser knows how to reach it. > -- I actually wrote the applet myself (on my system). > -- It runs perfectly well on my system. But it does not print > from Firefox on Linux (it does not print from Firefox when I > boot the computer into Windows, either; so far it only prints > from IE7 on Windows XP). > >> This is a reason you might think about whether an applet will >> be usable to all your visitors. I stopped using them years ago. > > Yes, from Googling I got the impression that there is a general > dislike of Java applets nowadays, among Web page creators. I do > not quite understand why. Could you elaborate? Actually, I ran across a microscope site a while back that had an applet animating light paths that I thought was a good use. But too many people have browsers that do not 'do' applets. Most applets you see are misused -- for instance, for navigation, cute animations of waves and such. > What alternatives > do you use for putting interactive programs on the Web? Server side processing, or DHTML/Ajax _if_ you can make them degrade gracefully. Flash/Java are still OK for some limited uses. > I am just > a Java newbie (what you could call a "very very late adopter") but > I was pretty impressed that my applet (which animates fairly > complicated mathematical things) That might be a good use... > asks nothing more from the server > than to serve up one file, of only 6003 bytes -- less than even a > small .png, .gif, or .jpg picture, for instance. > > Regards, Jan |
Re: Applet printing
In article <472b0f4f$0$25500$ba620dc5@text.nova.planet.nl>,
JWS <jws@my.home> wrote: > dorayme wrote: > > > Just a little thing, you should reconsider your > > > > line-height: 120%; > > > > Best to leave it out completely, or consider using a ratio: > > > > line-height: 1.2; if you must have it in. > > I thought I had that fixed already by specifying some other > line-height for h1, but apparently I hadn't. Thanks for pointing > it out. > > Anyway I now followed your suggestion of changing 120% to 1.2 > (without doing anything special with h1). To my amazement this > made a difference; the line spacing inside the h1 (if it is longer > than one line) is now correct. It doesn't change anything in the > rest of the page. I thought (from the CSS specs) that 1.2 and 120% > were just the same. > Also try the other thing I suggested and leave it out altogether (which is more elegant in that less is more, but I do not know if you have some special need for this figure, eg. in your applet?). As I understand it, the defaults for most browsers is about 1.2 so no real need in general to put this in. For your purposes perhaps no one will care about typographical subtleties when you are discussing the very interesting subject of material bodies slamming into other bodies? <g> > > Perhaps you will need more expert help with Java about why the > > radio buttons are too crowded together making the text disappear > > as in the 6 in the 16 and the 0 in the 50 for choice of Nmasses. > > This does not happen in any of the computers (Windows and Linux > only) or browsers that I tested it with. The distances between the > buttons are (must be in this case) fixed in pixels, so it seems > that your system has a bigger default font size than the systems I > used. No particular font was specified; I assumed (apparently > wrongly) that the java default font is always the same. BTW Are > the texts "Nmasses" and "Spring display" also too big? I mean, do > they run into the buttons on the right? They are "text" fonts > which may be different from "UI" fonts. > I am on a Mac and the view is rather the same in both Safari and Firefox (to take a couple of excellent browsers), perhaps this shot of the relevant bit will help you: http://netweaver.com.au/test/pics/jan_applet.png Just a thought for you: since your applet is not user sizable, err on the side of caution and have bigger fonts in it, better to do this than make them hard to read for some people. An applet like this looks quite suited to your modelling aims and well done for giving it a go! -- dorayme |
Re: Applet printing
dorayme wrote:
> Also try the other thing I suggested and leave it out > altogether No, I wouldn't do that; it is a taste thing. The 20% 'leading' makes the text (IMHO) more readable than when the lines are just packed together without strips of lead between them. I tried it again just now, and decided I really want the 20% extra space. Do you have an explanation of why 1.2 does not equal 120%? > [..] I am on a Mac and the view is rather the same in both > Safari and Firefox (to take a couple of excellent browsers), > perhaps this shot of the relevant bit will help you: > http://netweaver.com.au/test/pics/jan_applet.png Thanks much for this. It is really nice with this Mac look. FYI on my own (Linux/Firefox) system it has this much more impoverished look: http://www.jw-stumpel.nl/app-snap.png Not so nice, but at least you can see all the text. I use a 'minimalistic' type of Java which produces small files, and relies on the user's system to provide GUI elements like buttons, etc. Basically my studies have not progressed to the point where I can program more sophisticated Java. > Just a thought for you: since your applet is not user sizable, > err on the side of caution and have bigger fonts in it, better > to do this than make them hard to read for some people. AFAIK Java applets are never user-sizable. The size (in pixels) has to be set in the HTML which carries the applet (between the <applet> tags, <object> tags, or whatever). In this case the width is 800 pixels. There is simply no room for a bigger font; in fact, in the case of the Macintosh, it seems I would have to make the font smaller. It looks though that by juggling it a little bit, I could make it fit even on the Mac at your present font size. But this depends on the font size not changing. If you change the font size (or type) on your Mac, does the font in the applet change too, or is it fixed? In Windows and Linux, it is fixed. And BTW, how about print-previewing applets on the Mac? > An applet like this looks quite suited to your modelling aims Well, yes, that's what I thought too. I would think that Java applets are excellent for instructional / educational texts, and am in fact amazed that they have never really taken off. > and well done for giving it a go! Thanks. Regards, Jan |
Re: Applet printing
JWS <jws@my.home> writes:
> I finally managed to produce an applet, and put it on my page > (using the <applet> tag). I tried to make it look nice, with the > same background colour as the page itself. It looks just like the > other pictures on the page, the only difference being that it > moves when you press "run" (http://www.jw-stumpel.nl/bounce.html, > bottom of the page). One of the few well-justified uses of an applet I've seen lately. It's not required to view the page, but it does add value to the page for those who can use it. Very well done! > However, when I print (or print-preview) the page, Firefox (on > Linux and Windows) just shows a blank area where the applet should > be. IE7 prints the applet area correctly. As an additional data point, it doesn't print on FireFox/Mac either, but it *does* print on Safari/Mac. sherm-- -- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net |
Re: Applet printing
In article <472b6e1d$0$25482$ba620dc5@text.nova.planet.nl>,
JWS <jws@my.home> wrote: > dorayme wrote: > > > Also try the other thing I suggested and leave it out > > altogether > > No, I wouldn't do that; it is a taste thing. The 20% 'leading' > makes the text (IMHO) more readable than when the lines are just > packed together without strips of lead between them. I tried it > again just now, and decided I really want the 20% extra space. > > Do you have an explanation of why 1.2 does not equal 120%? As I said at the time of raising the idea of leaving it out, the default for most browsers is about 1.2. In other words, the browsers already use a css style sheet and on this style sheet you will see a value for line height. It is not 1. That would be too squashed for many fonts and sizes as you are correctly implying above. As you might appreciate, a pure number acts as a multiplier of the elements font-size. But a percentage is different. I rewrote the following to include a spiel on percentages which might explain the situation to you a bit. Please forgive me if there are any typos or mistakes. Will correct any that are pointed out of course: http://netweaver.com.au/test/lineHeight.html > If you change the > font size (or type) on your Mac, does the font in the applet > change too, or is it fixed? In Windows and Linux, it is fixed. And > BTW, how about print-previewing applets on the Mac? > It is fixed. And yes, it appears fine in my print preview from Safari. But not in Firefox. (Work on trying to get the applet to actually play on the printed page <g>) -- dorayme |
| All times are GMT. The time now is 04:27 AM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.