3420:22147 -- Custom Form Sizes being discarded?

OpenRPT
omfgppc
2009-03-16
2013-03-08
  • omfgppc
    omfgppc
    2009-03-16

    qbcsys1 wrote: I''ve been having a lot of trouble lately with trying to print on specialized 8.5\" by 8.5\" forms using a Dot Matrix printer, with no real rhyme or reason, and decided to take a look in the code to see if I can find out what''s going on.

    I have been looking into the code for the Print Renderer in OpenRPT, which I can only assume is handling the printing for these reports. (I''ve followed the trail from printInvoice.cpp, eventually ending up at orprintrender.cpp and pagesizeinfo.cpp).

    In the orprintrender, there is a section under setupPrinter() that deals with setting the page size:

    [code:1:05e018ff4f]
    ...

    PageSizeInfo psi = PageSizeInfo::getByName(pDocument->pageOptions().getPageSize());
      if(psi.isNull())
      {
        // TODO:
        psi = PageSizeInfo::findNearest((int)(pDocument->pageOptions().getCustomWidth() * 100), (int)(pDocument->pageOptions().getCustomHeight() * 100));
        if(psi.isNull())
          pPrinter->setPageSize(QPrinter::Custom);
        else
          pPrinter->setPageSize((QPrinter::PageSize)psi.qpValue());
      }
      else
        pPrinter->setPageSize((QPrinter::PageSize)psi.qpValue());

    ...
    [/code:1:05e018ff4f]

    From what I can deduce here, it seems like this is starting out by checking if we''re using a standard page size. If so, select it. If not, try to find the nearest page size, and if that doesn''t work, use a completely custom size. This wouldn''t be a problem normally, but since we''re working with dot matrix printers and continuously fed sheets, it''s not really good enough to be simply \"nearest\".

    [code:1:05e018ff4f]

    static PageSizeInfo __pages[] = {
      PageSizeInfo(\"A0\", QPrinter::A0, 3311, 4681),
      PageSizeInfo(\"A1\", QPrinter::A1, 2340, 3311),
      PageSizeInfo(\"A2\", QPrinter::A2, 1654, 2340),

    ...

    const PageSizeInfo & PageSizeInfo::findNearest(int w, int h)
    {
      int p = -1;
      int d = 99999;
      for(int i = 0; !__pages[i].isNull(); i++)
      {
        if(w <= __pages[i].width() && h <= __pages[i].height())
        {
          int t = (__pages[i].width() - w) + (__pages[i].height() - h);
          if(t < d)
          {
            p = i;
            d = t;
          }
        }
      }

      if(p == -1)
        return getByName(\"Letter\");

      return __pages[p];
    }
    [/code:1:05e018ff4f]
    Granted, there is a method there to use a custom size, but looking at the \"findNearest\" function in pagesizeinfo.cpp, it seems that if it does not find a matching page size in the list, then it simply defaults to letter, making the logic in the function above pretty much useless. (And in the case of an 850x850 form, \"Letter\" would come back as the closest match according to the logic in findNearest anyway.)

    Can anyone confirm whether this is what is actually happening here? Perhaps my tracking of the trail has been barking up the wrong tree, but if not, it seems like there really isn''t any way to do an actual custom size right now. I would love to be proven wrong if possible. -- Read more at http://www.xtuple.org/phpBB2/viewtopic.php?t=3420