Menu

#327 Printing illegible with non-monospaced editor font

v1.23
closed-fixed
nobody
General (289)
5
2012-09-17
2009-06-10
Aleksander
No

Printing to paper or pdf from Windows XP (wtih GTK) and Ubuntu 8.10 produces prints that are so badly prepared that they are difficult to read. Sample attached (from the Windows version using Acrobat Distiller). The results are the same for the other filetypes I use: php, perl, plain text, javascript.

I can't find versions, but here are the codenames and narrative listed in the Help About:
Windows: Argon built on or after Feb 15 2009
Ubuntu: Selit built on or after May 10 2008

(BTW Geany is a superb design superbly implemented, congratulations to the people behind this)

Discussion

  • Aleksander

    Aleksander - 2009-06-10

    Sample illegible printing with Acrobat Distiller in windows with Argon

     
  • Nick Treleaven

    Nick Treleaven - 2009-06-10

    Hmm, maybe this is because the font is not a fixed width font like Monospace.
    (But obviously supporting non-fixed width fonts is important too).

     
  • Enrico Tröger

    Enrico Tröger - 2009-06-10

    As Nick said, this is mostly about not fixed width fonts. The current code doesn't really support this, as your example PDF shows. The problem is we somehow need to know how many characters we can print onto a line to calculate how many line breaks we need and after all how many lines on a page we can print to know how many pages we will print at all. The problem is we need to know these information before we actually start rendering the pages.

    There are two trivial solutions:
    a) assume a constant width for characters and digits and do the above mentioned calculations
    b) render the whole text in memory, check what we need and use these values for the real rendering afterwards

    The first approach is what we currently do, it's much about calculation and even more about assuming and guessing, you already know the result.
    The second approach would probably give much better results but obviously require the document to be rendered twice which takes time, it really takes time even on fast machines.

    There is probably also a third way to do all this better but it needs to be figured out and finally implemented. I agree that the current printing code isn't really suitable for not fixed width fonts.

    Btw, wrt to version numbers: if you check the About dialog, the version number is written in the heading of the dialog, right-hand side of the icon. Maybe it's just too obvious :).
    Additionally, the version can be retrieved by running 'geany -V' on the command line.

     
  • Aleksander

    Aleksander - 2009-06-11

    Wow, excellent feedback! I am absolutely gobsmacked that an application has to do its own rendering for text. Every app on the planet has to be able to print, and text is such a common thing to print that there must be a standard driver or module or code bundle available, in fact dozens. I've spent some time yesterday evening searching, but unfortunately the terms related to printing and drivers are so common that the results are not helpful; need to know exactly where to look.

    Surely there must be some code you can simply copy and paste; there's no glory in re-inventing this wheel!

    I've just tested with monospaced fonts (Consolas in Windows and DejaVu Sans Mono in Ubuntu) and the results are excellent, very readable. No sample attached, you've seen such many times before.

    I believe it is safe to say that a workaround is to use monospaced fonts.

     
  • Enrico Tröger

    Enrico Tröger - 2009-06-11

    > I am absolutely gobsmacked that an application has
    > to do its own rendering for text. Every app on the planet has to be able to
    > print, and text is such a common thing to print that there must be a
    > standard driver or module or code bundle available, in fact dozens. I've
    > ...
    > Surely there must be some code you can simply copy and paste; there's no
    > glory in re-inventing this wheel!

    It's not that easy in case of Geany. I hope I won't you freak out by being too technically, but let me try (:D):
    Basically, you are right and a common printing API to easily get something done is already the case. Since some time there is direct printing in GTK, the toolkit we use and that makes printing very very easy.

    The problem in Geany is, we use Scintilla as the editing component and so we need to read the used styles (colours, font, bold, italic) and text from Scintilla and render it with GTK for printing. The native Windows port of Scintilla has some functionality to print directly using the Windows API. However, we use even on Windows the GTK port of Scintilla and so we can't make any use of this feature.

    To summarise, in general you are right, printing should not be anything special and I think this is also already the case in most matters. It's just that we have some kind of special with Geany, GTK and Scintilla which requires some additional code.

     
  • Nick Treleaven

    Nick Treleaven - 2009-06-11

    For now, perhaps we could add a warning dialog if the editor font is not a monospaced font. Maybe use
    something like pango_font_family_is_monospace() to check?

     
  • Enrico Tröger

    Enrico Tröger - 2009-06-11

    To use pango_font_family_is_monospace() we would need a PangoFontFamily object first and this isn't really possible, yet, AFAIK. See http://mail.gnome.org/archives/gtk-app-devel-list/2007-November/msg00090.html (I wrote this post exactly because of this, IIRC).

    :(

     
  • Nick Treleaven

    Nick Treleaven - 2009-07-09
    • summary: Printing illegible --> Printing illegible with non-monospaced editor font
     
  • Nick Treleaven

    Nick Treleaven - 2009-07-09

    Update: Geany SVN now at least shows a warning dialog if the editor font is not a
    monospaced font.

     
  • Colomban Wendling

    Now fixed in Git, thanks for reporting.

     
  • Colomban Wendling

    • status: open --> closed-fixed
     
  • Colomban Wendling

    • milestone: --> v1.23
     

Log in to post a comment.