I need to add printing capabilities to an app and I have been looking around for information about printing. Logical/physical sizes, dpi, font scaling, etc, lots to digest since I never programmed printing into any app before.
Are there any sites that would offer a primer on the topics of page sizes, margins and all the other elements required to understand printing on Windows? I've been looking around for a while but what I find is either cryptic or years old...
I've been playing around with TPrinter, but I would like to build solid printing functionalities and understand what I'm doing better.
Using a report solution is not an option, even though I'm sure it would provide better results much sooner.
Two links to get you started:
Printing with TPrinter
Printing via the TPrinter Canvas
I think that you are looking too lowlevel.
Try looking at the build reporting tools (Rave or whatever is in your product).
Personally i am using a product called Report Builder from Digital Metaphors.
But if you want to do the lowlevel stuff lot og good information can be found at efg's computer lab - printing
Well, I have done things a variety of ways in the past, including the "hard way" with TPrinter. In fact, I recently had to do that again to run a special inventory label printer.
On the other hand, sometimes you are better off taking work others have done and using it for your benefit. I agree that ReportSmith isn't so great, and also it's Delphi (and Windows) specific. Using Excel or Word has those limitations, plus the fact that the user has to actually have them installed.
One thing I have done to make printing easy for some simple applications is just to generate an HTML file and call the user's web browser, then they can print it. HTML tables can be created relatively easily for numerical data, and you can include photos, etc. as well. This works well for some applications, and works on every platform where a web browser is installed. The downside, of course, is that HTML isn't the most precise layout language.
The version of Delphi you´re using is important. A number of Delphis came with print engines like ReportSmith (ugh). Another option thinking laterally is to use MS Word as a print engine. I´ve hooked into instances of Word & Excel before & utilised their functionality. As to raw printing using TPrinter or the print method of TForm you´d have to be pretty desperate. I seem to recall the Pacheo / Texeira Delphi books coming with a pretty good overview so you might want to see if you can find a copy of that somewhere.
Related
There seems to be a lot of conflicting information out there. It might be that support has increased recently, or changes to adobe.com/air have made some information difficult to find - but I can't track down a definitive list of things to avoid.
I know that actionscript won't run in loaded SWFs, I know that some people say that filters and blendmodes and halo components won't work. I've also read many posts saying they will (at least that blendmodes will, and that halo will run, but slowly so still use spark)
I have a large amount of AS3 code to plan for upgrading to work on iOS, but at the moment I have no idea what things will break (or what things will break when those things have been fixed!)
Is there a list of unsupported APIs, or iOS dos and don'ts?
Thanks
:S
First, yes. Externally loaded SWF's will not run. You can however embed SWF's/SWC's into your project and include them inside of your package.
As far as Flex components, stay away from Halo. You should use Flex 4.6 and stick to components with mobile skins. I recommend downloading Tour de Flex http://www.adobe.com/devnet/flex/tourdeflex.html to get an idea of whats available.
As far as blend modes go, I'm not really sure. I haven't used them in mobile yet. However filters are supported but they are expensive. For drop shadows on rectangles there is something called RectangularDropShadow. This is actually a component and therefor less expensive. However it can only be used on rectangular groups.
You should have access all of the AIR API's. You will however be restricted when using some of File related classes since I don't believe you can leave your Appliaction Storage Directory.
One big performance tip I can give is to use AS3 over MXML whenever possible, ESPECIALLY when creating item renderers. Use BitmapImage over Image whenever possible, again especially in item renderers. Use cacheAsBitmap whenever you have images that don't change often. And stay away from any Flex component that doesn't have a mobile skin.
You may also want to read up on View and destruction policies.
http://www.adobe.com/devnet/flex/articles/flex-mobile-development-tips-tricks-pt1.html
This link also has some more performance tips
http://www.adobe.com/devnet/flex/articles/flex-mobile-performance-checklist.html
I need to generate a report/printout programmatically.
My app currently uses FastReport to build a report, consisting of text, images, tables etc.
It does not bind to any database. Everything is built programmatically.
However, the finished report does not look the same in PDF and RTF, and the old code is generally very complicated.
Are there any better tools to programmatically make a printout or report? Preferably one that outputs PDF and DOC.
In my opinion you've already got the best! I've used QuickReports, Piparti (early ReportBuilder), Crystal(!) and ReportBuilder and I've written a few reports by sending commands direct to the printer. As far as I'm concerned FastReport is much better (although I haven't tried Rave - nor will I).
Is it a recent version of FR? The PDF output for us is fine.
They have some good examples of writing reports through code on their website I believe and if you're looking at re-writing all the reports in A.N.Other reporting product why not, instead, use the opportunity to re-write the reports in a more maintainable way using FR? (Assuming that's possible, of course). Perhaps a cleaner approach to the code of the report generation will make it easier for the FR converter to create the RTF/DOC output...
I've never had much luck generating decent RTF versions of reports from commercial report writers. The only decent output I got was through lovingly hand coding every report using hundreds of '{','}' and '\' and spending days reading the RTF specs. Never again!
A lot of it appears to be down to the order you add the text/lines/fonts/styles etc to the report and the RTF generator can find it difficult to get the best rendering - I think.
You can try Rave Reports.
It has built in components to generate PDF, RTF and HTML documents.
And also it comes free.
For non-database printing needs, FastReport already works (code-based reporting), but for direct printing of Documents you could consider the very-thorough ExpressPrintingSystem from developer express, which is a true delphi printing system, not a reporting system.
Also if you need to create a print documents, almost like a word processor, and then print those word-processor-like documents, consider TRichView. It supports .DOC files, something you asked about.
Some day you might need a banded-report generator again and if you do, FastReport really is the best.
I am re-engineering a windows application to be ported to web. One area that has been worrying is 'printing'.
The application is data intensive and complex reports need to be generated. The erstwhile windows application takes advantage of printer APIs and extends sophisticated control to the users. It supports functions like page break, avoiding printing on printed parts of the sheet (like letterhead), choice of layouts and orientation, etc. Please note that these setting are not done only while printing, they are part of report definition sometimes.
From what I know, we cannot have this kind of control while printing web pages. I am in a process of identifying options at my disposal. While I prefer to first look into something that will help me print from raw web pages, following are other thoughts:
Since reports can also be exported to .xls & .pdf versions, let user download one and print directly. This however limits my solution to the area of application that have export feature.
Use Silverlight (4.0) for report layout definition and print. I think Silverlight 4.0 (in beta right now) provides adequate control over the printer. I have so far been avoiding the need of any RIA plugin.
Meticulously generate reports on web with fixed dimensions. I am not sure how far this will go.
Please share practices that can be applied easily in my scenario.
For reporting in the past on the web, using .NET, I like to generate PDF, Excel, Word or CSV files. I really like iTextSharp which allows for creating of PDF's.
Word can accept HTML, so that is usually quote easy. For more control you can get into the Word interops http://nishantrana.wordpress.com/2007/11/03/creating-word-document-using-c/, but they left me frustrated. Not for implementation, but I felt the clean up was poor.
CSV are great for raw data dumps and that is it.
For HTML, you can get nice control using a style sheet targeted to print media. There are just certain things you cannot control, like browser header and footer.
Flash also has better print controls than plain HTML, though you might not know it since these features are rarely used by flash developers. Almost everyone should have Flash installed these days, so it's not like Silverlight where there's a good chance of someone needing to install a plugin (doubly so for a beta version). I am not sure how the Flash printer APIs compare to Silverlight's printer APIs and if they give you the level of control you need, but their documentation is public so you can look into it.
Also I think exporting to PDF is a good idea. I don't see why you can't extend this to cover all places that would need to print a report. Basically instead of printing directly from the windows app running on their desktop, the same exact code runs on your server and generates a PDF that they can then print themselves.
I don't think you're going to have much luck trying to do it with raw HTML unfortunately. For one of our clients, we went with the "generate PDF" route and it worked out quite well. PDFs have the additional advantage that you don't have to print them out: you can just email them to the boss/accountant/whatever saving a bit of paper.
PDF is the way to go, if you want absolute control over printed output. As bonus, you can also provide the option to download PDFs in your application.
With HTML, you are at the mercy of user's browser settings for page size, margin and how page breaks will be handled.
It seems that most Delphi applications fit into two classes: Database-centric Applications that use Reporting Systems for all their printing needs, and applications that don't need printing.
For those in the excluded middle (non-database printing, non-reporting system), there are components to help out. For example, I have been a Developer Express "Express Printing System" customer since early on in that product's life cycle. For printing out any component (grid, spreadsheet,etc) that is also a Developer Express Printing System component to help me out.
So far so good. What I'm looking for is an alternative way (in Delphi 2010) to generate one or two page printouts that contain, typically:
Titles, and Headings
Page Headers and Page Footers
Ability to include a large picture which is the primary thing on the page. In this case, the picture (bitmap) is a chart custom drawn by me.
100% bulletproof output quality on every version of windows known to human kind, with every kind of printer known to human kind.
[UPDATE: I was previously having bizarre glitches with Developer Express printing components on color laser printers, which I am now quite hopeful I can sort out. ] ... Still I think it would be wise to look at other printing components out there so my "toolbox" of possible solutions for my current and future projects can include a simple reliable way of generating printer pages.
So I could really use suggestions. I am biased against Reporting Systems, even Code Based ones, but I am considering fast reports even though my use for it would be far from the typical use-case scenarios. There are no row and column data-sets involved in my printed pages.
Update/Final: It looks like FastReports is great. It can easily transfer any data from in memory in your application (such as an Image), to the current report page(s), like this:
procedure TForm2.Button1Click(Sender: TObject);
var
pic:TfrxPictureView;
begin
pic := frxReport1.FindObject('Picture1') as TfrxPictureView;
pic.Picture.Assign(Image1.Picture);
frxReport1.ShowReport;
frxReport1.Print;
end;
Fast Report is suited my needs very well. They even have a scripting system. You could try if is good enough for you.
http://fast-report.com/en/
I have been using the HtmlViewer component from www.pbear.com for all my printing solutions.
You have to create an html page (or two pagews) of course, but once you can do that, you can do anything you like (or at least what the html standard supplies). The HtmlViewer has a preview window so that can be used as a generic 'report' viewer and it can print the output immediatly.
You will be amazed what you can do with html, and it is easy to change the 'report' because it's just plain html.
If you should go that way, I will be happy to assist you in any question you might have. The component is free since a couple of years. So that could be an easy and inexpensive solution to your problem.
What's the best way to set up help (specifically HTML Help) for a Delphi application? I can see several options, all of which has disadvantages. Specifically:
I could set HelpContext in the forms designer wherever appropriate, but then I'm stuck having to track numbers instead of symbolic constants.
I could set HelpContext programmatically. Then I can use symbolic constants, but I'd have more code to keep up with, and I couldn't easily check the text DFMs to see which forms still need help.
I could set HelpKeyword, but since that does a keyword lookup (like Application.HelpKeyword) rather than a topic jump (like Application.HelpJump), I'd have to make sure that each of my help pages has a unique, non-changing, top-level keyword; this seems like extra work. (And there are HelpKeyword-related VCL bugs like this and this.)
I could set HelpKeyword, set an Application.OnHelp handler to convert HelpKeyword requests to HelpJump requests so that I can assign help by topic ID instead of keyword lookup, and add code such as my own help viewer (based on HelpScribble's code) that fixes the VCL bugs and lets HelpJump work with anchors. By this point, though, I feel like I'm working against the VCL rather than with it.
Which approach did you choose for your app?
When I first started researching how to do this several years ago, I first got the "All About help files in Borland Delphi" tutorial from: http://www.ec-software.com/support_tutorials.html
In that document, the section "Preparing a help file for context sensitive help" (which in my version of the document starts on page 28). It describes a nice numbering scheme you can use to organize your numbers into sections, e.g. Starting with 100000 for your main form and continuing with 101000 or 110000 for each secondary form, etc.
But then I wanted to use descriptive string IDs instead of numbers for my Help topics. I started using THelpRouter, which is part of EC Software's free Help Suite at: http://www.ec-software.com/downloads_delphi.html
But then I settled on a Help tool that supported string ID's directly for topics (I use Dr. Explain: http://www.drexplain.com/) so now I simply use HelpJump, e.g.:
Application.HelpJump('UGQuickStart');
I hope that helps.
We use symbolic constants. Yes, it is a bit more work, but it pays off. Especially because some of our dialogs are dynamically built and sometimes require different help IDs.
I create the help file, which gets the help topic ID, and then go around the forms and set their HelpContext values to them. Since the level of maintenance needed is very low - the form is unlikely to change help file context unless something major happens - this works just fine.
We use Help&Manual - its a wonderful tool, outputting almost any format of stuff you could want, doc, rtf, html, pdf - all from the same source. It will even read in (or paste from rtf (eg MSWord). It uses topic ID's (strings) which I just keep a list of and I manually put each one into a form (or class) as it suits me. Sounds difficult but trust me you'll spend far longer hating the wrong authouring tool. I spent years finding it!
Brian