<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <meta http-equiv="CONTENT-TYPE" content="text/html;
      charset=ISO-8859-1">
    <p style="margin-bottom: 0.2in">I have been investigating Geany's
      problems with printing.<br>
      <br>
      I looked at<br>
       * Geany 1.22<br>
       * Geany - the current git (as of a few days ago when I started
      this) <br>
       * Geany 1.23 (git >= 8855c14), en_US.UTF-8<br>
       * SciTE 3.1.0<br>
      <br>
      <br>
    </p>
    <p style="margin-bottom: 0.2in">Geany 1.22 - problems <br>
       * When
      counting pages, tabs are not expanded, giving inaccurate results -
      #3475444<br>
       * Printing code mishandles non-monospaced fonts -
      #2804000<br>
       * When printing, tabs are expanded to fixed width, not to
      the next tab stop - #2629121.<br>
       * When user requests to print a
      specified page, page 1 is printed and labeled the requested
      page.<br>
      For example, if the user selects to print page 7 only,
      Geany will print <br>
      page 1, but in the heading, the text will
      read “Page 7 of xx”. I didn't <br>
      submit this as a developer
      bug, since it is fixed in the current version.</p>
    <p style="margin-bottom: 0.2in">Geany – the current git -
      problems<br>
       * Print Preview displays a different number of lines than
      hard-copy - #3580269.<br>
       * The line separating line numbers from text
      when printing is positioned incorrectly - #3580268.<br>
       * Printed lines
      are right-shifted compared to previous Geany versions, <br>
      causing
      wrapping which did not occur in previous Geany versions.</p>
    <p style="margin-bottom: 0.2in">SciTE problems<br>
       * Print Preview
      displays a different number of lines than hard-copy.<br>
      <br>
      <br>
    </p>
    <p style="margin-bottom: 0.2in">The git version of Geany contains a
      new version of the printing code. This new version uses the
      printing
      code contained within Scintilla. </p>
    <p style="margin-bottom: 0.2in">The Scintilla printing code does not
      draw a vertical line between the line number and the text. So the
      git
      version of Geany attempts to draw that line. However, Scintilla
      provides no method of determining the width of the line number
      column
      (SSM(SCI_GETMARGINWIDTHN) returns the display margin
      width, not the printer margin width). So the Geany code attempts
      to mimic the
      calculations Scintilla performs to come up with the column width.
      The
      attempt fails, thus bug #3580268.</p>
    <p style="margin-bottom: 0.2in">The Scintilla printing code adds
      three spaces between line number and text. This shifts the text
      right, and lines which were nearly page width when printed using
      the
      previous versions of Geany now wrap.</p>
    <p style="margin-bottom: 0.2in">As a quick check whether the lines
      per page mismatch between Print Preview and hard copy is in
      Geany's
      code or Scintilla's, I tested SciTE. SciTE has the same problem.</p>
    <p style="margin-bottom: 0.2in">Using the git version of Geany, I
      printed page 1 of a particular test document, Print Preview listed
      the document as 18 pages long with 51 lines on the first page (4
      lines wrapped) and the hardcopy listed it as 19 pages long with 45
      lines on the first page (8 lines wrapped).</p>
    <p style="margin-bottom: 0.2in">Printing the same test with SciTE,
      Print Preview listed 55 lines on page 1 with 3 lines wrapped, and
      hardcopy listed 44 lines with 7 lines wrapped. (SciTE's output
      does
      not show the number of pages in the document).</p>
    <p style="margin-bottom: 0.2in">I have investigated the problems
      with
      the old (1.22 and before) printer code, and I believe all can be
      addressed by modifying the original code, with the exception of <br>
      Printing code mishandles non-monospaced fonts - #2804000<br>
      <br>
      <br>
    </p>
    <p style="margin-bottom: 0.2in">I fixed the bug “When printing,
      tabs are expanded to fixed width, not to the next tab stop -
      #2629121” locally a few weeks ago. That was why I joined the
      developers group. I wanted to submit that patch.</p>
    <p style="margin-bottom: 0.2in">I have not noticed any discrepancy
      between Print Preview and hardcopy with the (tab expansion
      patched)
      old code. And the old code naturally knows the correct location
      for
      the vertical line.</p>
    <p style="margin-bottom: 0.2in">When determining the number of pages
      in the code, the old code currently determines the length of each
      line by multiplying the width of one character by the number of
      characters in the line. That is correct as far as UTF8 is
      concerned –
      it uses a UTF-aware function to determine number of characters.
      But
      it fails to take into consideration the expansion of tabs.</p>
    <p style="margin-bottom: 0.2in">To fix this problem in the old code,
      one could replace the page counting code. Take the lines of code
      that
      actually do the printing, put those lines into a separate
      function,
      and call that function twice. First time, the function would
      calculate the layout (and thus the number of pages) but not
      actually
      print. Second time, it prints. If only certain pages are
      requested,
      second time it skips lines til a requested page's first line, then
      prints the page, then skips lines til the next requested page,
      etc.</p>
    <p style="margin-bottom: 0.2in">Once tabs are expanded correctly,
      this change seems to fix all the issues except non-monospaced
      fonts.</p>
    <p style="margin-bottom: 0.2in">An option to deal with that could be
      to use the new code only for non-monospaced fonts. For monospaced
      fonts, use the old code. For non-monospaced fonts, the issue of
      Print Preview not matching hardcopy would remain, but IMO that is
      a
      Scintilla bug, and depends on that group for a fix.</p>
    <title></title>
    <meta name="GENERATOR" content="LibreOffice 3.5 (Linux)">
    <style type="text/css">
        <!--
                @page { margin: 0.79in }
                P { margin-bottom: 0.08in }
                A:link { so-language: zxx }
        -->
        </style>
  </body>
</html>