Applet printing

Discussion in 'HTML' started by JWS, Nov 2, 2007.

  1. JWS

    JWS Guest

    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
     
    JWS, Nov 2, 2007
    #1
    1. Advertising

  2. JWS

    dorayme Guest

    In article <472af49a$0$13746$>,
    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.
    >
    > 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
     
    dorayme, Nov 2, 2007
    #2
    1. Advertising

  3. JWS

    JWS Guest

    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
     
    JWS, Nov 2, 2007
    #3
  4. JWS

    mbstevens Guest

    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
     
    mbstevens, Nov 2, 2007
    #4
  5. JWS

    JWS Guest

    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
     
    JWS, Nov 2, 2007
    #5
  6. JWS

    mbstevens Guest

    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
     
    mbstevens, Nov 2, 2007
    #6
  7. JWS

    dorayme Guest

    In article <472b0f4f$0$25500$>,
    JWS <> 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
     
    dorayme, Nov 2, 2007
    #7
  8. JWS

    JWS Guest

    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
     
    JWS, Nov 2, 2007
    #8
  9. JWS <> 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
     
    Sherman Pendley, Nov 2, 2007
    #9
  10. JWS

    dorayme Guest

    In article <472b6e1d$0$25482$>,
    JWS <> 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
     
    dorayme, Nov 3, 2007
    #10
  11. JWS

    Ben C Guest

    On 2007-11-03, dorayme <> wrote:
    > In article <472b6e1d$0$25482$>,
    > JWS <> 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 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


    I think the point is that if you inherit a percentage line-height, you
    get that percentage of the font-size of the ancestor that you inherited
    line-height from.

    This is because you don't inherit it as a percentage, but you inherit
    the result of that percentage applied to the ancestor it was set on.

    But if you inherit a pure number line height, you inherit it _as a pure
    number_, and you get that multiplied by your own font-size.

    The spec is rather unclear on this:

    <number>

    The used value of the property is this number multiplied by the
    element's font size. Negative values are illegal. The computed value [p.
    88] is the same as the specified value.

    <percentage>

    The computed value [p. 88] of the property is this percentage
    multiplied by the element's computed font size. Negative values are
    illegal.

    They sound the same, until you consider inheritance: you compute the
    computed value before bequeathing a property to your descendents.

    So, in your example, #percentage has line-height: 72% and font-size:
    50px. Its computed line-height is therefore 36px. So <p class="small">
    inherits 36px directly, not 72%.

    But if you give #percentage line-height of .72, then <p class="small">
    inherits .72 (since for <number>, above, "the computed value is the same
    as the specified value"). That's why in that case it gets .72 of its
    _own_ font-size.
     
    Ben C, Nov 3, 2007
    #11
  12. On Nov 3, 1:08 am, JWS <> wrote:
    ....
    > ...What alternatives
    > do you use for putting interactive programs on the Web? ..


    Your applet is well suited to being launched using Java
    Web Start* (JWS, coincidental with your posting name!).
    It would end up as 'free floating', but then, this type of
    animation applet hardly needs a browser window wrapped
    around it.

    If you wanted to take it further, it seems also well suited to
    being deployed as a screensaver, I could throw it up on-screen
    and watch those harmonic patterns for hours. If interested,
    check the SaverBeans** project.

    * <http://www.physci.org/jws/#jtest>
    ** <https://screensavers.dev.java.net/>

    Andrew T.
     
    Andrew Thompson, Nov 3, 2007
    #12
  13. JWS

    JWS Guest

    dorayme wrote:

    > As I said at the time of raising the idea of leaving it out, the
    > default for most browsers is about 1.2.


    But not for Mozilla products on Linux! I definitely need the line
    in the css. That is why I didn't understand, at first, your
    suggestion to leave it out. I just rebooted into Windows and
    messed with my css, and you are right, 20 % of leading is applied
    by IE and Firefox by default (I do not know where exactly this is
    set). So I would suggest that for the benefit of the Linux users,
    line-height: 1.2 (not 120%) should be put into the css. It does
    not harm the Windows and (presumably) Mac users.

    Linux users can also set it by default on the user side by editing
    userContent.css, but I would guess most users do not even know
    that this file exists.

    Regards, Jan
     
    JWS, Nov 3, 2007
    #13
  14. JWS

    dorayme Guest

    In article <>,
    Ben C <> wrote:

    > On 2007-11-03, dorayme
    > >
    > > http://netweaver.com.au/test/lineHeight.html

    >
    > I think the point is that if you inherit a percentage line-height, you
    > get that percentage of the font-size of the ancestor that you inherited
    > line-height from.
    >
    > This is because you don't inherit it as a percentage, but you inherit
    > the result of that percentage applied to the ancestor it was set on.
    >


    Certainly right. I chose the absurdly big 'ancestral' 50px to
    help see a case of this.

    > The spec is rather unclear on this:


    I agree. As so often, One stares at the specs, forms about 4
    alternative pics in the brain as to what the meaning or
    implications really are, shrugs, makes some test cases and the
    pennies start to drop - with any luck. Then one goes back to the
    specs and they look a bit clearer. <g>

    --
    dorayme
     
    dorayme, Nov 3, 2007
    #14
  15. JWS

    Ben C Guest

    On 2007-11-03, dorayme <> wrote:
    > In article <>,
    > Ben C <> wrote:
    >
    >> On 2007-11-03, dorayme
    >> >
    >> > http://netweaver.com.au/test/lineHeight.html

    >>
    >> I think the point is that if you inherit a percentage line-height, you
    >> get that percentage of the font-size of the ancestor that you inherited
    >> line-height from.
    >>
    >> This is because you don't inherit it as a percentage, but you inherit
    >> the result of that percentage applied to the ancestor it was set on.
    >>

    >
    > Certainly right. I chose the absurdly big 'ancestral' 50px to
    > help see a case of this.
    >
    >> The spec is rather unclear on this:

    >
    > I agree. As so often, One stares at the specs, forms about 4
    > alternative pics in the brain as to what the meaning or
    > implications really are, shrugs, makes some test cases and the
    > pennies start to drop - with any luck. Then one goes back to the
    > specs and they look a bit clearer. <g>


    Indeed, I only figured out what the spec was talking about after looking
    at your example.

    But if you read the bit about "cascading" it does explain (more or less)
    that it's computed values that are inherited. That suddenly makes the
    line-height section make more sense.
     
    Ben C, Nov 3, 2007
    #15
  16. JWS

    dorayme Guest

    In article <>,
    Ben C <> wrote:

    > On 2007-11-03, dorayme <> wrote:
    > > In article <>,
    > > Ben C <> wrote:
    > >
    > >> On 2007-11-03, dorayme
    > >> >
    > >> > http://netweaver.com.au/test/lineHeight.html
    > >>


    > >> The spec is rather unclear on this:

    > >
    > > I agree. As so often, One stares at the specs, forms about 4
    > > alternative pics in the brain as to what the meaning or
    > > implications really are, shrugs, makes some test cases and the
    > > pennies start to drop - with any luck. Then one goes back to the
    > > specs and they look a bit clearer. <g>

    >
    > Indeed, I only figured out what the spec was talking about after looking
    > at your example.
    >
    > But if you read the bit about "cascading" it does explain (more or less)
    > that it's computed values that are inherited. That suddenly makes the
    > line-height section make more sense.


    Yes, it does. All a matter of it registering, be nice if it was
    at the time one consults the specs. I have always been impressed
    by how some people here (including you of course) seem able to
    read the specs with as much clarity as you do. I tend to have to
    do it with more hindsight. I recall Jukka Korpela pointing out
    about the trap of units for line-height in an exchange with me
    ages ago and it was a salutary lesson.

    --
    dorayme
     
    dorayme, Nov 3, 2007
    #16
  17. JWS

    Ben C Guest

    On 2007-11-03, dorayme <> wrote:
    > In article <>,
    > Ben C <> wrote:
    >
    >> On 2007-11-03, dorayme <> wrote:

    [...]
    >> > I agree. As so often, One stares at the specs, forms about 4
    >> > alternative pics in the brain as to what the meaning or
    >> > implications really are, shrugs, makes some test cases and the
    >> > pennies start to drop - with any luck. Then one goes back to the
    >> > specs and they look a bit clearer. <g>

    >>
    >> Indeed, I only figured out what the spec was talking about after looking
    >> at your example.
    >>
    >> But if you read the bit about "cascading" it does explain (more or less)
    >> that it's computed values that are inherited. That suddenly makes the
    >> line-height section make more sense.

    >
    > Yes, it does. All a matter of it registering, be nice if it was at the
    > time one consults the specs. I have always been impressed by how some
    > people here (including you of course) seem able to read the specs with
    > as much clarity as you do. I tend to have to do it with more
    > hindsight.


    It's all hindsight on my part too, but you do reach a point (after a lot
    of trying things out) where the penny drops and you can tell what most
    of it is talking about.

    But then it still isn't so easy to explain it because you find yourself
    starting to use the same incomprehensible jargon yourself.

    > I recall Jukka Korpela pointing out about the trap of units for
    > line-height in an exchange with me ages ago and it was a salutary
    > lesson.


    As far as I can see one almost always would want to use 1.2 rather than
    120%. That's the simple lesson to take away here.
     
    Ben C, Nov 3, 2007
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rob Love

    applet vs. canvas in applet

    Rob Love, Jul 7, 2003, in forum: Java
    Replies:
    1
    Views:
    636
    Liu, Chunyen
    Jul 7, 2003
  2. webster
    Replies:
    0
    Views:
    873
    webster
    Jul 20, 2003
  3. Andrew Thompson
    Replies:
    0
    Views:
    423
    Andrew Thompson
    Aug 5, 2003
  4. Blah Blah
    Replies:
    0
    Views:
    1,442
    Blah Blah
    Aug 13, 2003
  5. Jade
    Replies:
    3
    Views:
    938
    Roedy Green
    Aug 14, 2003
Loading...

Share This Page