3

This problem is well known, but I've yet to find a solution.

Whenever the fon-size in windows is set to higher then the normal size

the report shrinks relative to the paper size,

and gets anchored to the top left corner of the page like so:

Image1

Swiching the "scaled" property on or off anywhere doesn't effect this.

As is messing with PixelsPerInch.

The only solution offered from those I've seen, that actually does something,

and can be found in quickreport forum, in this link right here:

QrPreview with UseDpiScaling under Windows7 ,

involves creating a new project manifest resource, adding the following lines to it:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </windowsSettings>
  </application>
</assembly>

However the only thing this does is make the text in the report larger,

while the report stays within the same boundries, as illustrated below:

Image2

What can be done about that?

I need the report to fit the size of the paper,

to display and print the same way it was designed, regardless of windows font-size

user1349751
  • 81
  • 1
  • 6
  • In fact the entire VCL has issues scaling properly to these DPI settings. I've even seen Microsoft software itself appear horribly when this is changed. One of the most common complaints from our customers. We always tell them that setting should always be on 100%, and that Microsoft should never have made this option available in the first place. – Jerry Dodge Sep 19 '14 at 00:50
  • I have no issues with QR and large fonts, because the printer font has nothing to do with the screen font. QR does print preview to a metafile which is then displayed on the screen, but I've experienced no difficulty either in designing, previewing, or printing with Windows screen font sizes using Delphi and Windows 7 with a large variety of applications, reports, and 50 users with various font, DPI, and screen resolution settings in 20+ applications and about 1000 reports. – Ken White Sep 19 '14 at 03:01
  • @Jerry Font scaling is essential for high pixel density screens. These are common now. It's not hard to do it right. – David Heffernan Sep 19 '14 at 03:46
  • Just to emphasize, our company has done custom edits to the QuickReports library to be able to work with with our software. Specifically the preview in our own common print preview screen. – Jerry Dodge Sep 19 '14 at 05:53
  • @ken Seems to me you have the solution, but you don't know what it is :( – user1349751 Sep 19 '14 at 08:50
  • Changing the entire QR source, replacing every "Screen.PixelsPerInch" with "96" also doesn't work. – user1349751 Sep 19 '14 at 11:33
  • Every form in my project has scaled propery set to "False", so my project should 100% ignore windows font size settings. – user1349751 Sep 19 '14 at 11:34
  • I don't have a solution, because I don't have a problem. :-) I transitioned to Windows 7 (from XP) about two years ago, while the majority of our systems were still on XP. We then migrated all of our users (in groups of 5-10) over to Win7, and made zero changes to any of our apps related to QR, and all reports (design, preview, and printing) just work. – Ken White Sep 19 '14 at 12:56
  • @Ken Would you do me a favour then, and send the QR source via yousendit or dropbox or something, and then post the link here? I would very much like to look at it, and compare it with mine. – user1349751 Sep 19 '14 at 14:41
  • I have 1000+ reports, all of which are connected to our data. I'm not sure what report you'd like me to send or what good it would do you (or which I could send that wouldn't reveal company info inappropriately). Also, sending you files off-site wouldn't be in keeping with this site's purpose, which is to share knowledge with everyone; a personalized answer placed somewhere else wouldn't do so. The majority of our reports are set to use US standard 8 1/2" x 11" paper, standard margins, and normal Windows fonts and sizes, all with the default Windows character sets. We do some labels as well. – Ken White Sep 19 '14 at 16:03
  • @Ken I don't mean the reports or your application, just the quickreport source, it's about 3.5 MB when compressed – user1349751 Sep 19 '14 at 17:08
  • @Ken yes, I know about the purpose of the site, and I'm definately not after any inside scoop on any company or software. the source of the quickreport should ideally not contain any information about your company. I just think this would help figuring out a solution and sharing it with developers who have encountered the same problem. That's what this is all about for me :) – user1349751 Sep 19 '14 at 17:14
  • Sorry, misunderstood your request. I'm afraid I can't send you the QR source; we purchased licenses for QR3 Pro, and transferring that source would be a violation of licensing. QR is a commercial component set, and the Borland/CodeGear/Embarcadero versions don't include source. If you need it, contact [the vendor](http://www.quickreport.co.uk/). – Ken White Sep 19 '14 at 17:20
  • @Ken you could just post the content of quickrpt.pas, qrprev.pas, qrprntr.pas into pastebin, and i'm pretty sure that won't be a violation of anything. It may prove helpful to me, but if you're feeling reluctant, I understand. Thanks – user1349751 Sep 19 '14 at 17:21
  • Providing copyrighted source code that we've licensed from a vendor to someone else is indeed a violation of that license. (As the files you listed are the majority of the content of the product, I'm not sure how you'd think it wouldn't be one.) As I said before, if you need access to the source code contact the vendor; they offer it for sale (which is how we obtained it). I'm not violating the license terms by posting the source here or anywhere else. Sorry. – Ken White Sep 19 '14 at 17:29
  • I've got a high pixel density display and need to use 200% font scaling. I won't be able to read the text in your app well. I will not be inclined to use it. – David Heffernan Sep 19 '14 at 19:25
  • My understanding is that QuickReport 5.06 sorts this out (at least to some degree). You do need to set the Stretch property on the form used for QR, and the comments on the QR 5.06 release notes say that it is a fixed defect. – quickly_now May 06 '15 at 02:03

1 Answers1

0

I found a working solution! Patch for QRPrntr.pas:

  procedure TQRPrinter.CreateMetafileCanvas;

  function scaleToNativeDeskRes(pVal: Integer): Integer;
  var
   tTemp: HDC;
  begin
    tTemp := GetDC(0);
    try
      Result := Round((pVal * GetDeviceCaps(tTemp, VERTRES)) / GetDeviceCaps(tTemp, DESKTOPVERTRES));
    finally
      ReleaseDC(0, tTemp);
    end;
  end;

begin
...
  FMetafile.Width := scaleToNativeDeskRes(XSize(PaperWidthValue));
  FMetafile.Height := scaleToNativeDeskRes(YSize(PaperLengthValue));
  FCanvas := TMetafileCanvas.Create(FMetafile, 0);
  FCanvas.Font.PixelsPerInch := MetafileDPI;
...
end;
bhe
  • 51
  • 1
  • 2