search

alinebee / Boxer

The DOS game emulator that's fit for your Mac.
http://boxerapp.com/
770 stars 139 forks source link

Changed Printer rendering from character based to AttributedStrings #46

Closed tclaus closed 1 year ago

tclaus commented 9 years ago

One drawback of the original printing system is, that every character is printed separately. As noted in the source comments, kerning and ligatures are not possible. Another nasty thing is, that underlines are dashed (see the attachments 'original' and 'after'.

Technically I Made a character line puffer with an NSMutablaeAttributedString, every time a line feed or a horizontal or vertical Head moves, the line puffer will be rendered to the view, and a new line buffer is started.

Things still ToDo:
I decided to move the default font from "Roman" to "Helvetica" since this looks more modern on printings. A settings dialog to let the user choose which default font to use would be nice.

In the "original" attachment you can see that the colons (:) in the bill are nicely in one column. I didn't get it in the new printing that they are nicey one under the other.

The kerning - Old printer have the CPI setting - a nice way to convert the CPI to a meaningful kerning value should be found.

I have only one dos application that needs to print bills, I can not test this with other apps and can not test it with images etc. Hope that pull request will help to get a full useable dos printing.

Regards VVAanchesa

Before: teamworker_original After: (Underlines are now correct, but still some issues with the character alignment. Need help.. teamworker_withkerning

alinebee commented 9 years ago

It's great to see the print emulation getting some love!

As you note, batching up the character rendering into strings allows OS X's text rendering engine to do its magic, providing us with proportional spacing, kerning and ligatures, and giving much better results for underlines and strikethroughs. It would also semantically group characters into words in the PDF output, which makes text selection work better in PDF readers. (OS X's builtin Preview app does a good job of detecting words by character proximity, but I expect other readers are not so adept.)

The problem with this approach, as you've discovered, is text alignment: rendering multi-character strings using proportional fonts will screw up the strict column layout that's guaranteed by a dot-matrix printer and assumed by the DOS application.

I consider this a dealbreaker for the kinds of DOS applications that people are likely to use this emulation for: namely old financial software and spreadsheets, which have to print grids of figures in column layouts, and whose output becomes nearly unusable (like your billing example) if printed proportionally.

I think it should be possible to build an NSAttributedString-based text renderer that compensates for this by playing with the leading/kerning attributes of each character, so that the overall character width matches the expected dot matrix output. This would give the best of both worlds.

(On the other hand, printing proportionally without regard to column layout is desirable for DOS word processors, since long-forrm text is much more readable that way. I can envisage a "Use proportional printing" checkbox for this in the Print Preferences panel, which you could toggle depending on whether you needed strict layout or pretty text respectively. Behind the scenes, this would simply enable or disable the character width-correction.)

So! I won't incorporate this change as-is, but I think it's on the right track, and if it could be revised to (optionally) produce correct character widths then it'll be a winner.

alinebee commented 9 years ago

A couple of notes on coding style btw:

tclaus commented 9 years ago

Thank you for the quick response - and more thank you for the hints about code styling. I will revise this. Could you mind to implement a printer preference panel then? Changing proptional and fixed length characters should be as easy to change font between "Arial" (or any Sans Serif - Font you like" to something with a fixed character width. So we don't have to voce playing with character-by character kerning and spacing.

alinebee commented 9 years ago

The trouble with relying on the system's monospace fonts is that they're still not monospaced to the same width as the dot matrix printer's 10-, 12- and 15-CPI modes, so the output still won't match the column layout expected by the DOS application. If the font is narrower than the DOS application expects then there's no real harm done, but if the font is wider then the text will run off the edge of the page and/or cause characters to be wrapped to the next line unintentionally.

I realize that the onus is on the user to choose an appropriate font in such cases; but I feel it would be best if the default behavior was correct emulation of the printer's expected output, and the user can then opt out of correct spacing for print tasks where it's appropriate.

All this aside, there's another issue to be considered with user-modifiable print preferences: by the time the OS X print panel comes up (where the user would normally be able to change their print preferences), the pages have already been rendered by the emulated printer and cannot be modified. If the user changes the font or spacing settings there (which they should be allowed to do), the entire print job would need to be re-rendered. In order to do this, the printer should capture and 'play back' all the inputs it has received from the DOS application during the current print session, rendering them into a new canvas.

tclaus commented 9 years ago

I don't think that the user will or need to print the page and then change the font. A page re-rendering is nothing more than simply hit the application print-button again.

For me the result is now OK: I switched to a default monospace font ("Menlo") and the characters are now in a column. (Spacing is the poor mans tabulator..) I also changed some code styling issues as you mentioned.

This is the result from an old billing application: teamworker_monospace font

alinebee commented 9 years ago

The output certainly does look a whole lot better with a well-designed monospace font! I agree that Menlo is a good choice for the default; looks like it was introduced in Snow Leopard, which is the minimum version targeted by this Boxer branch, so should be fine.

How big an impact are the kerning adjustments having on the result? Does the font still cope well at 12 and 15-CPI modes? (I'm on vacation at the moment and not able to test the code.)

The rationale for updating the print preview is that it's fairly straightforward to capture and replay those inputs and would save a lot of time for the user: they can see near-instantly how their changes affect their document, whereas the DOS application may take a long time to retransmit its signals to the emulated printer (especially when there's graphics to be printed). That's kind of independent of this particular feature though, I was just thinking out loud.

tclaus commented 9 years ago

The kerning now have a fixed factor that suits for my case (10CPI I think), I can currently not really test 12 or 15CPI, my billing application has no such of preferences. I am now considering installing very old turbo pascal for DOS and write a little test application and simulate some printer settings.. BTW: "Boxer" is the very first time that I am contributing on the git hub platform. If the kerning with the other CPIs are correct Boxer will be the first, only and most complete DOS simulator! Yeah! Have a nice vacation - in the meantime I try to build a small test application.

alinebee commented 9 years ago

FWIW I've done most of my printer testing with a copy of MS Word 5.1 for DOS I found online somewhere: this can print PCX-format images, and allows the selection of different 'sizes' of fonts (which in this case just means different widths).

tclaus commented 9 years ago

Hello Alun,

the new printing functionality is now under productive use by my customer, but I think there are still some issues to fix:

There should be some kind of (simple) view to set the font ?

The nice print animation looks nice, but is not really useful (for me). My use case is a (very) old printing application which prints page-by page and not line-orientated. I don’t know how much other application have the need for a line-by-line approach.

So - how could I help you to integrate the branches and make the latest changed to the printing engine to a productive branch?

BTW: Testing printing with an old Word for DOS is a pain in the ass.. I could swear, the print preview in Word lies about the real printing output. The different font styles and sizes can only be printed by using the graphics mode. By using the characters - mode of the old printers the different sizes, styles and so word promises on are not possible. I ended up with a little quick-basic code ans sending the ESC-Sequences by code.

I have attached the quick basic with the „printer.bas“ for testing purposes.

Regards, Thorsten

Am 29.08.2014 um 16:20 schrieb Alun Bestor notifications@github.com:

FWIW I've done most of my printer testing with a copy of MS Word 5.1 for DOS I found online somewhere: this can print PCX-format images, and allows the selection of different 'sizes' of fonts (which in this case just means different widths).

— Reply to this email directly or view it on GitHub.

tclaus commented 8 years ago

Alun, believe me or not, these printing enhancements are still im use by one of my friends/customers. But with the latest automatic update it got lost and I had to copy my local development again. would you mind to have a new start to review my pull request and make the needed steps (for me) to finally include this useful pice of code in the master branch? What do you think? regards, Thorsten