trichview.support
Re: Printing with ReportBuider |
Author |
Message |
Justin Turberville |
Posted: 04/05/2002 20:24:16 Yes, prnsad.ppiyDevice = 96 aswell, so it seems to be what the state of the canvas passed to RVReportHelper.Init. I noticed that prnsad.ppiyDevice = 600 in your native printer. One problem is that if previewing, the printer canvas has not yet been initialized becaused the printer has not yet been selected, which is awkward with TRVReportHelp.Init as it has to be called before previewing. Even after forcing the canvas font to 600ppi and verifying that that is what it is when the RVStyle is doing its TextOut, it still prints out with huge fonts. "Sergey Tkachenko" <svt@trichview.com> wrote in message news:3cadbd24$1@support.torry.net... > 96 is a pixels-per-inch value of screen. > But for RichView printing, it should be equal to ppi of printer > (prnsad.ppiyDevice). For example, for my HP LJ 1100 ppi=600 (600 dots per > inch) > > Is value of prnsad.ppiyDevice = 96 too? > > > > > > if > > > TCustomMainPtblRVData(FHelper.RichView.RVData).PrnSaD.ppixDevice>TCustomMain > > PtblRVData(FHelper.RichView.RVData).PrnSaD.ppiyDevice then > > lPrinter.Canvas.Font.PixelsPerInch := > > TCustomMainPtblRVData(FHelper.RichView.RVData).PrnSaD.ppiyDevice > > else > > lPrinter.Canvas.Font.PixelsPerInch := > > TCustomMainPtblRVData(FHelper.RichView.RVData).PrnSaD.ppixDevice; > > > > The ppi always seems to be 96 and aribitrarily changing it (*20, /2, etc) > > does'nt make any difference, which is is indicative of the problem, I > > suppose. > > > > I did a similar posting to ReportBuilder support and they've requested my > > wrapper to check out. > > > > It will be in all our interests to get this working. > > > > "Sergey Tkachenko" <svt@trichview.com> wrote in message > > news:3cac96ee@support.torry.net... > > > Is Canvas.Font.PixelsPerInch set to the printer resolution? > > > > > > > > > > We have made a RichView support component for use in ReportBuilder > > > > (Piparti). The preview is now working reasonably well, but with the > > > > printing, while the page starts in the correct position after the > report > > > > header and ends without writing over the report footer, the font is > way > > > > larger than it should be. Embedded pictures are drawn at the correct > > > > position and size and a table's frame is also correct in position and > > > size, > > > > so we seem to have the scaling correct - it's just the @#$ font! The > > page > > > is > > > > being drawn to ReportBuilder's printer canvas and not directly to the > > > actual > > > > printer canvas, but it's canvas is being set to the correct font style > > on > > > > TextOutA in TFontInfo.Draw, so it seems to be some sort of canvas > > setting, > > > > or probably more likely, ReportBuilder is doing some sort of stretch > > copy > > > to > > > > the actual printer canvas that is scaling the graphics, but not the > > > fonts - > > > > but the problem does not exist with other ReportBuilder components. > > > > > > > > Any suggestions? > > > > > > > > > > > > > > > > > > > > |
Powered by ABC Amber Outlook Express Converter