OK. Your suggestion on the font sizes worked correctly. Many thanks. If it moves you, I would like to know your thought process to make that suggestion.

OK. Your suggestion on the font sizes worked correctly. Many thanks. If it moves you, I would like to know your thought process to make that suggestion.

Glad it helped

Well, I read what you tried, I read the documentation, and compared what you tried to my understanding of the docs (including html), and I examined what the values of the constants were

Basically , you verify everything starting with the problem-causing-line until you encounter a difference between what you think should happen and what you observe to happen -- usually these revelations are loud AHA!-types with a solution, or so confusing that you're forced to put-aside what you're working on and start a new file to create the smallest possible example that replicates the problem

Its a lot like debugging CGI scripts or any kind of program, you need a mental model of how its supposed to work (Cwd, STDIN/STDERR/STDOUT/@ARGV/%ENV), what is special about perl ( PERLLIB/PERL5LIB/PERL5OPTS, perlvar, @INC ), what is special about CGI (Server error, see CGI Help Guide , Troubleshooting Perl CGI scripts)

You know input comes on STDIN, output goes on STDOUT, and if things stop making sense and you haven't been able to force an error message, you start making your own error message (turn on debugging/logging, add print statement), you start verifying that STDIN contains the input that is supposed to be there, that pwd/cwd is what you think it should be, and %ENV, and @ARGV ... and @_ are what the function takes

You always start with the big picture, an overview(like wxWidgets overviews), a bird's eye view of how something is supposed to work ( like HTTP ), then look at some simple examples, then bigger examples, until the big idea is firmly planted in your headn. Then write lots of little programs to explore/test/verify how each part is supposed to and does work.

Then when debugging a real program, you have a built-in debugging checklist to verify against. If you're well designed libraries (Dancer/Catalyst...) they'll do a lot of the checking for you, make errors obvious, but you'll be lost without a mental model (aka "domain" or metaphor) , error messages won't make sense, and programmers need a few just to get started (stdin, args, return values, exit codes, files and folders/directories ...)

Its a lot like being a car mechanic or an animal tracker, you start with a model/behaviour of a car/animal, you look to see what tracks/diagnostics you're getting, you ask yourself, if I were fuel/camel and I were leaking/thirsty, which way would I turn? And then turn left/replace leaky carburetor :) How Non-scientists use the Scientific Method

a lot more links on this type of thing and related things and examples if you've got time and need some perspectives and perspectives

Also known as teddy bear debugging , mirror debugging, empty room debugging, talking to yourself, Rubber Duck method of debugging, say it out loud George, sing into that hairbrush ... Re^3: Move along, nothing to see here . . ., Re: On Answering Questions

Read more... (2 kB)

I don't really understand how defining larger values will result in a smaller printout

Me neither, but it might have some effect on the text being unreadable -- if you start up notepad and try specifying font size as zero or negative , I get something quite unreadable. If you use font sizes smaller than default but still readable, it might work :/

BTW the constructor for $htmlwindow is in the initialization subroutine.

:) yes, I assumed as much, but that doesn't help the code run on my computer