Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
EDIT : I completed this project using ABCpdf. For anyone interested, I love this product and their support is A+. Everything I listed as a 'Con' for the HTML -> PDF solution was easily doable in ABCpdf.
I've been charged with creating a data driven pdf report. After reviewing the plethora of options, I have narrowed it down to 2. I need you all to to help me decide, or offer alternatives I haven't considered. Here are the requirements:
100% Data driven
Eventually PDF (a stop in HTML is fine, so long as it is converted)
Can be run with multiple sets of data (the layout is always the same, the data is variable)
Contains normal analysis-style copy (saved in DB with html markup)
Contains tables (data for tables is generated at run-time)
Header/Page # on each page
Table of Contents
.NET (VB or C#)
Done quickly
Now, because of the fact that the report is going to be generated with multiple sets of data, I don't think a stamped pdf template will work since I won't know how long or how many pages a certain piece of the report could require.
So, I think my best options are:
Programmatic creation using an iText-like solution.
Generate in HTML and convert to PDF using a third-party application (ABCPdf is the tool I have played with so far)
Both solutions have their pro's and con's.
Programmatic solution:
Pros:
Flexible
Easy page numbering/page header/table of contents
Free
Cons:
Time consuming (to write a layer on top of iText to do what I need and keep maintainable)
Since the copy is already stored in the db with html markup, I would have to parse through the data before I place it into the pdf, ensuring I don't have to break the paragraph into chunks so I can apply bold, italic, underline, etc. to specific phrases. This seems like a huge PITA, and I hope I am wrong about that assumption.
HTML -> PDF
Pros:
Easy to generate from db (no parsing necessary)
Many tools for conversion
Uses technology I am already familiar with
Built-in "Print Preview" - not a req, but nice
Cons:
(Edited after project completion. All of my assumptions were incorrect and ABCpdf is awesome)
1. Almost impossible to generate page headers - Not True
2. Very difficult to generate page numbers Not True
3. Nearly impossible to generate table of contents Not True
4. (Cross-browser support isn't a con; Since its internal, I can dictate what browser to use)
5. Conversion tool quirks - may not convert exactly as rendered in browser Not True
6. Overall, I think it would be very hard to format the HTML exactly as I would want it to appear/convert to PDF. Not True
That's it - I need the communitys help in deciding which way I should go. I might be wrong about some of my Pro/Con assumptions. If I am, please tell me. All thoughts and suggestions are welcome and appreciated.
Thanks
Decided on using an approach similar to the one used at
http://alistapart.com/articles/boom
Using ABCPdf instead of Prince for the eventual HTML -> PDF generation.
Anyone who is interested in the same thing, feel free to message me about this approach.
I think that if you have a full version of Adobe Acrobat Pro, it comes with Adobe Live Cycle. You should be able to produce reports generated from a database from it. It will give you everything you need in formatting since you will create the report from scratch.
You can create a database connection to an OLE database that will feed data to your form fields. You select the tables to be used, any stored procedures that will run, any queries, and then the data will appear on one of the pallettes in the designer.
You can also use Web Services (WDSL) to receive and process commands and return the results to the form.
Either way, you would bind fields to your data source and then the data would be displayed in your form.
If you're willing to do a little .NET work there's this:
http://www.dotnetvj.com/2009/05/populating-pdf-from-aspnet-using.html
Depending on which platform you are using and targeting, you might want to consider a reporting solution. These are not perfect but the one thing they do give you is the ability to write a report once and then render it in HTML, PDF, or even Excel.
Usually they also provide an editor that helps you design the report and make it look just right. They provide things like paging, headers, footers, graphs, etc. They also provide an API that you can use to programatically create and run the reports.
I've used Reporting Services in a MS environment and Jasper Reports in a Java environment with good results in both. I'm sure there are other options but these are the ones I've been able to use successfully.
For the HTML→PDF step, I really love Prince. It looks like you can call it from VB.
My recommendation is to use SQL Reporting Services.
Can design every page & table of your report
Include Header and Footer
Include Page Numbers
Table of Contents
Can span through multiple pages
Supports Images & Charts
Can be rendered to PDF without a need for any thrid party PDF Converters
Related
I was wondering if anyone knew of an application that would take a GEDCOM genealogy file and convert it to HTML format for viewing and publishing on the web. I'd like to have separate html files for each individual and perhaps additional files for other content as well. I know there are some tools out there but I was wondering if anyone used any tools and could advise on this. I'm not sure what format to look for such applications. They could be Python or php files that one can edit, or even JavaScript (maybe) or just executable files.
The next issue might be appropriate for a topic in itself. Export of GEDCOM to RDF. My interest here would be to align the information with specific vocabularies, such as BIO or REL which both are extended from FOAF.
Thanks,
Bruce
Like Rob Kam said, Ged2Html was the most popular such program for a long time.
GRAMPS can also create static HTML sites and has the advantage of being free software and having a native XML format which you could easily modify to fit your needs.
Several years ago, I created a simple Java program to turn gedcom into xml. I then used xslt to generate html and rdf. The html I generate is pretty rudimentary, so it would probably be better to look elsewhere for that, but the rdf might be useful to you:
http://jay.askren.net/Projects/SemWeb/
There are a number of these. All listed at http://www.cyndislist.com/gedcom/gedcom-to-web-page-conversion/
Ged2html used to be the most popular and most versatile, but is now no longer being developed. It's an executable, with output customisable through its own scripting syntax.
Family Historian http://www.family-historian.co.uk will create exactly what you are looking for, eg one file per person using the built in Web Site creator. As will a couple of the other Major genealogy packages. I have not seen anything for the RDF part of your question.
I have since tried to produce a Genealogy application using Semantic MediaWiki - MediaWiki, the software behind Wikipedia, and Semantic MediaWiki includes various extensions related to the Semantic Web. I thought it is very easy to use with the forms and the ability to upload a GEDCOM but some feedback from people into genealogy said that it appeared too technical and didn't seem to offer anything new.
So, now the issue is whether to stay with MediaWiki and make it more user friendly or create an entirely new application that allows for adding and updating data in a triple store as well as displaying. I'm not sure how to generate a family tree graphical view of the data, like on sites like ancestry.com, where one can click on a box to see details about the person and update that info or one could click on a right or left arrow around a box to navigate the tree. The data comes from SPARQL queries sent to the data set/triple store both when displaying the initial view and when navigating the tree, where an Ajax call is needed to get more data.
Bruce
I have a requirement for users to create, modify and delete their own articles. I plan on using the WMD editor that SO uses to create the articles.
From what I can gather SO stores the markdown and the HTML. Why does it do this - what is the benefit?
I can't decide whether to store the markdown, HTML or both. If I store both which one do I retrieve and convert to display to the user.
UPDATE:
Ok, I think from the answers so far, i should be storing both the markdown and HTML. That seems cool. I have also been reading a blog post from Jeff regarding XSS exploits. Because the WMD editor allows you to input any HTML this could cause me some headaches.
The blog post in question is here. I am guessing that I will have to follow the same approach as SO - and sanitize the input on the server side.
Is the sanitize code that SO uses available as Open Source or will I have to start this from scratch?
Any help would be much appreciated.
Thanks
Storing both is extremely useful/helpful in terms of performance and compatiblity (and eventually also social control).
If you store only Markdown (or whatever non-HTML markup), then there's a performance cost by parsing it into HTML flavor everytime. This is not always noticeably cheap.
If you store only HTML, then you'll risk that bugs are silently creeping in the generated HTML. This would lead to lot of maintenance and bugfixing headache. You'll also lose social control because you don't know anymore what the user has actually filled in. You'd for example as being an admin also like to know which users are trying to do XSS using <script> and so on. Also, the enduser won't be able to edit the data in Markdown format. You'd need to convert it back from HTML.
To update the HTML on every change of Markdown version, you just add one extra field representing the Markdown version being used for generating the HTML output. Whenever this has been changed in the server side at the moment you retrieve the row, re-parse the data using the new version and update the row in the DB. This is only an one-time extra cost.
By storing both you only have to process the markdown once (when it is posted). You would then retrieve the HTML so that you can load your pages faster.
If you only stored one, you'd forever have to recreate the other for either the display view or the edit view.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
How do you implement user documentation in Access? I've never bothered with formal user documentation in the past; I tend to rely on good interface design to guide users (or so I tell myself). But I'd really like to know what people smarter than me are doing...
Here are things I think I would consider important (in order):
Simplicity: it needs to be simple enough that it can be updated easily as the code changes, otherwise the documentation will end up out of sync
Screen shots: a picture's worth a thousand words; screen shots must be easily integrated into the documentation
Integration: the user can get to the relevant part of the documentation with as little effort as possible; ie, pressing F1 on a form brings up help for that form vs. opening a help file and having to navigate a table of contents
Searchable: full-text search capabilities would be nice
Other considerations:
Online vs. local: local would be faster/more reliable, but online would be always available plus search engine indexable (allowing use of google site: searches and providing some SEO benefit as well)
User Editable: how much do you allow users to make changes to the documentation: full access (ie, wiki), no access, moderated forums, etc.
Version control: text-based formats are more conducive to versioning than say, an Access table with help text inside the mdb
Exportable to PDF: seems like a nice-to-have
In Access I've never created end user documentation. No wait, I did once about 12 years ago. And I paid someone to write the manual along with screen shots. I did also have the hlp files, etc, etc. But I don't recall the details now.
Now for the Auto FE Updater, where appropriate, I have a text control which is underlned and blue which the user can then click on. The code then opens up their web browser to the appropriate page on my website using the ShellExecute API Much simpler for me than trying to figure out some kind of help system that would work for both offline and online. I also update the ToolTip control to put in the exact URL so they can see where they are going to go if they click on the text control. That's a VB 6 program but close enough for your requirements.
You may find HTML Help suitable.
I don't produce documentation for my client projects unless the client pays me big $$$ for it, as it's extremely difficult. I often guide users in producing in-house materials that document procedures and standards, but in general, I design my apps for EASE OF USE.
That is in contrast to EASE OF LEARNING.
EASE OF USE and EASE OF LEARNING often conflict with each other, as a UI design that makes it really easy to perform a task the first time often gets in the way once the user is accustomed to how things work.
However, it's important to design the UI with two things in mind:
things that are done on a daily basis don't need to be easy to learn -- they need to be really fast and friendly for the person who already knows how to use the app. I have a 10+20 rule -- 10 minutes of training and 20 minutes of use and the user will never forget how to use it.
things that are done only very seldom should be designed with a UI that is transparent and easy and doesn't require the user to remember anything at all. These kinds of tasks are great candidates for wizard-style interfaces that step the user through the process and provide hints and tips as text along the way.
I also have a number of UI design conventions that I implement throughout an app. The example that springs to mind is that any subform that is a datasheet or continuous form has a doubleclick event that when activated opens a popup form with the full details for the selected record. Once users grasp this convention, they will assume that any subform is doubleclickable in order to navigate to the detail.
There are other such conventions, but that's the basic idea, i.e., to implement similar behaviors in similar contexts so that if a user learns to do something in one context, when she finds herself in a different place with a similar UI, the things learned in the original context are transferrable in terms of basic UI behavior.
You will need to do two things:
Create a help file with topic-ID's for all of the topics
Link this help file to your access database, and link the topics
We have had very good results with http://www.helpandmanual.com/. From one single source, you can create any sort of help file that you want: pdf, online, chm, hlp, xml, ... It has a screenshot tool integrated.
Every topic can have it's own ID and you can just link your access forms / controls to this ID.
I have done a very similar thing to Tony. Its kind of a user generated content type thing let me explain.
The database contains a table with a list of the form names and then the path of a help file (word doc) that corresponds with that form.
Certain users have access to a form that allows them to say what help file corresponds to each form
Each form then has a help button so when the user clicks on it they open up the correct help file.
This way it is totally flexible, if they just want one big help file then all the links point to that but if the users want to put the effort in then they can make a file for each one. As they help files are separate from the DB storage is not a problem and also help files can be changed without having to recompile the application.
You could merge this idea with Tony’s and have the help files online if you wanted. I just find this a nice design pattern
I recently stumbled upon TiddlyWiki and have been thinking about using that as a backend to the systems Kevin and Tony described.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We currently use ActiveReports (by Data Dynamics, now Grape City) for canned reports, but are considering moving up to their Reports package. If you've used it, I'd love to hear your take on:
Performance - do you feel it will scale well for a web based app (particularly compared with ActiveReports)
Export to Excel - it appears to provide a much cleaner export to Excel (ActiveReports' Excel export is awful, our biggest reason for considering a switch)
Other pros/cons (my company is pretty small, the $3,000 for 2 licenses is a lot for us)
Here are some additional information for you to consider about ActiveReports & Data Dynamics Reports:
ActiveReports Licensing:
There license is per developer. There are no royalties. You can write as many applications as you want and deploy your application to as many users or as many servers as you want without any additional costs. Read the ActiveReports License agreement here.
Reporting to Excel:
First of all, schooner is absolutely correct that all the other reporting tools have a poor scenario when exporting to excel. We recognized the same after many years of experience with ActiveReports. Frankly, it is a very hard problem to take reports designed to be paginated or deployed on the web and put them into a cell-based layout of a spreadsheet.
However, with Data Dynamics Reports', we took a completely different approach. Instead of creating just another "export to Excel", where we look at "paginated" report output and try to fit it into a spreadsheet somehow, we generate the excel output based on two things: A template and the actual data in the report.
By using a template, which is actually a specially formatted excel sheet (cells have some special place holders in them) the reporting engine can output the report's content to an excel sheet completely independent of how the report is laid out when paginated. We call this concept a "Transformation Extension" for Excel since it takes the report's content and transforms it to excel based on a template.
By default DDReports will generate a default template that you will find more often than not has pretty good output. However, if the excel output is not what you want, you can instruct DDReports to save the template so you can customize the output in excel.
The best way to get an introduction to this is to watch the screencast for the Excel Transformation Extension in Data Dynamics Reports here. Jump to about 1:20 in the screencast if you get impatient and see an example of a simple template. Keep in mind this is a very simple template and the possibilities are much more sophisticated. Unfortunately, thus far we haven't published very good documentation on using the excel transformation extension template syntax yet, but let me know if you have questions and I'll help you out! Just comment on this post or send an email to our support team.
Scott Willeke
Data Dynamics / GrapeCity
I've used it and it rocks! It has a Report Designer control that allows you users to build thier own reports on the fly and supports multiple datasources used in a single reports. Best reporting tool on the market bar none.
We use both products and they are quite different from each other. I have been a long time user of Active Reports and have loved them. But when it came time to select a .net reporting tool we did not want to spend a bunch of $$ so we decised to get their DDR product. It took me a couple of weeks to get used to it as I kept trying to use it like Active Reports. Not a good idea. Anyways, once you get used to it it does a decent job. there are some things that they need to do to improve the product. Here are the things that stand out.
You cannot access the control collection in the code area. This is a huge problem if you want to change anything like data binding inside the report.
The database connection have to be refreshed if you repopen the report int he designer. This took a while to figure out and we wondered why our fields would not show up in the preview mode when re reloaded the report.
Their new tech support is terrable. They were bought out recently and now when you call tech supprt you get someone tht has no knowledge that always tells you that someone will call you back. 80% of the time you get no call back. The otehr 20% of the time you get a sample emaild to you that has nothing to do with your issue. Now this is accorss the board with both products. THey used to have great tech support. I hope they fix this.
Those are the main problems and I know they are workign to solve the issues. Like i said we use boh DDR and Active Reports. If you need to do complicated reports stick with Active Reports. If they are simple and you do not want to spend a lto fo money then DDR works fine. I see DDR getting better with each release but it will take a while to get the knks worked out.
Just my opinion
I've only used ActiveReports as well, but their web licensing model is a bit expensive in general in my view, espeically if you need to develop multiple apps on multiple servers. Then there is the per developer costs as well.
I use DevXpress XtraReports and have been fairly happy with it so far and it has some fairly decent export functionality and a much better licensing model.
Regarding export to Excel, I've not seen any reporting tool do it well, mainly due to the formatting issues with the report itself. What we typically do is provide the formatted report to the user, along with an additional link for an Excel export which is a similar but different query with the raw data the report uses.
Another option over formatted printable reports is using grids such as Infragistics which allow you to do sorting, grouping, summaries, and which has excellent Excel export features.
This is to give more information to Bill's response in this thread. I tried to post a comment, but ran out of room :)
Bill Thanks for your honest assessment. Let me give some comments for you from the inside on the issues you mentioned:
1: Admittedly it is not quite as intuitive to access the controls collection as it was with AR, but you /can/ do it. You need to do it outside of the report (not in the script/code embedded into the report). To do it you can load the rdlx file in a ReportDefinition object. For example:
var rpt = new DataDynamics.Reports.ReportDefinition(new FileInfo("myfile...rdlx"));
var list = (DataDynamics.Reports.ReportObjectModel.List)rpt.Report.Body.ReportItems["myList"];
var txt = (DataDynamics.Reports.ReportObjectModel.TextBox)list.ReportItems["myTextBox"];
txt.Value = "=Fields!MyField.Value";
However, depending on the scenario you're after there may be a better way to handle this than changing the binding on the control/reportItem itself. It is difficult to say more without knowing more about your particular scenario/goals.
2: There was recently some discussion I was involved in on how to improve this in the very near future. The dev team was gathering use cases and doing some investigation on various caching strategies to keep hitting the database to an absolutely minimum in the designer. So look for improvements in this area in an upcoming build.
3: Unfortunately, we're working through some challenges with our new technical support team. However, we are improving constantly and we're working hard to bring up the new guys as quickly as possible. If you have a problem with one of your incidents with support feel free to email me personally with your case number and I'll work to try get your case escalated or help out in any way I can (scott dot willeke at grapecity dot com).
Thanks again for your feedback, my next letter is an internal one based on your feedback to help us improve!
Scott Willeke
Program Manager
Data Dynamics / GrapeCity inc.
I have used this product since 2004. Great performance, licensing was great. The migration from earlier versions was great. It had its flaws like ghost images for high speed high volume in production environment and missing some of the goodies you get with Crystal and bar codes issues. But this the engine was fast. Then came version 7. What a mess!! rendering a 4 x 4 label went from 320 ms to 800 ms. Try getting a patch... Good luck with that. Try getting someone on the phone suddenly became like winning lottery. If performance is not a factor and you need just simple reports, go for it. Otherwise, think twice. As for us, this is the last version if our QA can pass it. We're shopping for a replacement product.
They are good and I am not trying to frighten you, but below is the fact, in my perspective :
Pros
Active Community ... you can expect responses overnight.
Good stuff to get you started - walkr-thrus, tutorials, examples, vides etc
Internal builds - Just like Linux kernel patches you can get "hot fixe" for the problems their developer team was able to solve
Web report viewer is available and also works within Visual Studio - just like other reporting tools.
Cons
Week rendering engines - you can not expect that they are going to be exported to word/excel w/o any issues, if you use a sub-report in a table row.
Poor bug fixes - takes over a year to fix a bug - I am following one since 11-11-2011, still they keep saying "we will let you know as soon as we fix this bug"
Not too active to release stable versions. - It takes a year some times for the, to release the next stable version.
Low control over rendering, you may not use events if you wish to embed some code, but yes, Data Dynamics does provide VB.net (and just VB.net ! ) (Custom Code) support, you may use it for validation typo stuff
I am sharing some links for your reference:
forums | How to section | Walkthrough(s) | Useful resources | drill throughs | videos | Convert Crystal reports (Remember: vice versa is not possible) | online help / Documentation - User Guide | Web Report Viewer
I am working on a project converting a "spreadsheet application" to a database solution. A macro was written that takes screen shots of each page and pastes them into a PowerPoint presentation. Because of the nice formatting options in Excel, the presentation looks very pretty.
The problem I'm having is that I haven't ever seen an Access report that would be pretty enough to display to upper management. I think the output still has to be a PowerPoint presentation. It needs to look as close as possible to the original output.
I am currently trying to write some code to use a .pot (presentation template) and fill in the data programmatically. Putting the data into a PowerPoint table has been tricky because the tables are not easy to manipulate. For example, if a particular description is too long, I need to break into the next cell down (word-wrap isn't allowed because I can only have n lines per page).
Is there a way to make an Access report pretty, am I headed down the right path, or should I just try to programmatically fill in the Excel spreadsheet and use the code that already exists there to produce the presentation? (I'd still need to figure out how to know when to break a line when using a non-monospaced font, as the users are currently doing that manually when they enter the data in the spreadsheet)
Jason Z:
If I set it to wrap, and I already have n lines, it would make n+1 or 2 lines on the slide, which is unacceptable.
Dennis:
That article looks very good, I should be able to glean something from it. Thanks!
Access has the capability to create downright beautiful reports. The problem is that it can't make a spreadsheet look better than Excel. You have to know when to use each tool.
Use Excel when you have spreadsheet-like formatting, need a lot of boxes and lines, or want to draw charts.
Use Access when you will output a report as a PDF. It's very useful for one-record-per-page detail reports, formatting where you need to position things very precisely, and where you need to embed subreports with related or unrelated data.
Think about the reports that would be nasty in Excel because you'd have to merge cells all over the place and do funny things with the placement and the layout would never work. That's where Access shines.
Joel, (your co-host here) did a thing about using access reports for shipping labels a few years back... maybe this could be a inspriation for you?
http://www.joelonsoftware.com/articles/HowToShipAnything.html
I have implemented Access reports which were 'pretty' enough. The downside is that it takes a lot of time and effort, and trial and error to produce the desired output.
You can definitely get there, but it requires the patience of a saint.
I guess it depends on what you mean by pretty. For example, I do not find it particularly difficult to produce say, reasonable graphs and tables with alternate line shading in Access. It is also possible to use MS Word and fill in bookmarks, or mail merge. If the present system uses VBA to create the PowerPoint presentation, perhaps much of it could be transferred to Access? Microsoft have an article on Access to Powerpoint: http://msdn.microsoft.com/en-us/library/aa159920(office.11).aspx
Finally, it is not impossible to build HTML output from Access.
We create multi-colored, conditionally formated, reports that are printed for the partner meeting each month of a publically traded corporation. They're real pretty.
I would suggest that the problem you're having is because the requirement to replicate the old method identically is an incredibly bad idea.
You're not using Excel any more.
You're using a different tool with different capabilities.
Thus, you will use different methods to get results.
Re-evaluate the original requirements to see if they still make sense (e.g., exactly why is PowerPoint involved at all? Can PowerPoint import from the Access report snapshot viewer? Can PowerPoint import from a PDF produced from an Access report?), or if they are too connected to the old tools, and then determine what is important and what isn't, and only then should you start designing your solution.
I personally would not try to re-invent the wheel here. If you already have an Excel sheet that has the formatting you want, just export the data from Access into Excel for the report. Now, if you didn't have the original Excel sheet to begin with, that would be a completely different story.
As for breaking lines with non-monospaced fonts, have you tried setting the cell format to wrap?
It sounds like the path of least resistance is to fill in the Excel spreadsheet. We have a contractor who does our Access stuff, and for the more complicated reports he uses Excel. I guess complicated == hard to make look good.
Rather than filling in the excel spreadsheet programmatically, you may want to use the external data features of Excel and Access. Generally I put a query on each tab, which of course may be hidden. An "update all" causes all the queries to be updated. Then summary tabs show the pretty results from all the individual queries.
For one particularly complex system, a bit of excel vba programmatically changed a query and then walked through the tabs updating each one.
Finally, rather than doing screen shots, Excel has a "copy cells as a image" copy that populates the copy buffer with a resizeable image. This could give you better looking results than a pure screenshot since a screenshot can have various deficiencies depending on pixel density.
Just an update:
After a few hours of work, I was able to get a nice report out of Access (almost an exact copy of the excel version). It wasn't as difficult as I thought, I just had to figure the correct mixture of out subreports and pagebreaks.
Working with the wordwrap features of Excel/Powerpoint were a dead end because there could only be a set number of lines per page, period; plus I was too lazy to nail down all the pagination with VBA code issues myself. Like Shelley says, Access shines at report generation.
The output ended up being a PDF (Using Adobe Acrobat Professional). The problem I have left is getting select pages of said PDF into Powerpoint without Powerpoint antialiasing the results for me and making the resulting slide's text fuzzy. I found a couple of articles on converting .snp output to .wmf, which sounds like the way to go on that front.