Document creation and editing online - pdf-generation

What language or technology would I need to be able to create documents online? I want to be able to add text and images and move them into position, resize etc, similar to this.
And then when complete, create a PDF from them.
Sorry if this is a bit vague, I just need to know where to start researching.

You need to decide on your basic technology: Flash, Silverlight, Canvas, client-side SVG, server-side SVG or server-side bitmap. There are also commercial solutions that work with Adobe InDesign documents (and probably a host of other proprietary formats) but I'd expect those not to be cheap.
Flash/Silverlight require plugins, and are considered by some to be a dying technology - though I am sure that is disputed. Canvas is 'very HTML5' and is essentially a bitmap built/rendered on the client, but if you are ultimated rendering to PDF it may not provide the resolution you need. The same limitation affects building an image server-side too - you should probably be dealing with vector elements plus bitmaps, rather than rendering everything to pixels as you go.
That leaves SVG in my list, either on the client (see RaphaelJS) or on the server (see Inkscape). I'm doing some work with server-side SVG rendering at the moment, and it is promising; although subject to more scalability issues than client-side, it doesn't suffer from browser-compatibility issues or the limitations of browser rendering.
The biggest issue in browser SVG rendering is flowed paragraph text and text in/on a path - I am not sure how well these are implemented in modern browsers, or how much agreement there is between them. This is especially the case given that some of these require SVG1.2, and browsers (afaik) are only just settling on SVG1.1, after many years. But, if you just want to do standard blocks of text, bitmaps and vector elements, browser-based SVG should suit you fine.
The example you've given uses a server-side technology (SVG, or perhaps a commercial format) and renders to low-res PNG on the client.
In your case, once you've considered how to 'do the editing', you'll need to consider how to render to PDF, which will be done on the server. You could go low-level and use something like FPDF, use a report renderer like Jasper, or use a graphics system like GhostScript, Inkscape, Scribus, ps2pdf, svg2pdf etc.
Aside: I normally don't answer questions without obvious prior research. But, since you've indicated that you will indeed undertake this, I'm happy to help get you started.

Related

CMS WYSIWYG Editors - What techniques do you use to client-proof these types of pages?

This is a topic that may be considered something not necessarily "programming related"; however, I feel it is since I'm asking for specific techniques.
Essentially, as a web developer, I work with a variety of platforms that include a WYSIWYG editor in the backend (TinyMCE, WYGWAM, etc) and one of the selling points of such systems is that it becomes easier to manage your own content because of these tools.
In theory, sounds great, in practice, not so much.
It can be way too easy for a client to break a layout by using many of the advanced features of a WYSIWYG editor. They can start floating things, setting too much margin/padding, etc.
Generally, I have tried to build any of these types of pages with only some sensible default styles applied to a few of the most common tags, such as setting a font size, colors, some margins, and some text decorations.
I would like to know if anyone has used anything more advanced to essentially turn the output of:
$cms->getContent();
...or equivalent into something that is effectively sandboxed and operates entirely agnostic of any other style/layout elements being used.
As often as possible, I express to clients that they should purchase an HTML/CSS book for Dummies and read it so that they aren't deer in headlights when they click "code view" in a WYSIWYG. But I know they don't do this, nor do they hire anyone who has experience, and it ends up allowing a client more control than they should responsibly have.
Plus, it sucks when you are using their sites as work samples to show others knowing they have the ability to take your beautiful design and development and make it look like crap.
A few things:
I have a standard WYGWAM config that I reuse on new sites by importing the exp_wygwam_configs table.
I keep options very limited in the editors
Areas of the page delineated for images should use a File field, with an image resizer like CE Image used to insure proper size
Client training. Make videos with Camtasia or similar tool if you have to.
Use a custom stylesheet for WYGWAM that has a small subset of styles, so they can choose h2...h4, for example, but not h1 or h5.
After encountering a lot of issues with WYSIWYG editors (which, by the way, never reflect accurately what you "get" in the end), I now prefer to leave only the most basic formatting features in the editor's configuration. For example, take a look at stackoverflow's editor.
It's got the following features: bold, italic, link, quote, pictures, lists, and alignments. The only special feature here are code sample and html, which are targeted to this site's audience. Most of your client don't need them.
I think it's the best approach, because if you give your clients the feeling that they can do whatever they want in the page, but in the end, this content is filtered when the page is rendered, they are going to be really frustrated. Not to mention the fact that the site will be slowed by the filtering process and the need to put the filtered content in cache.
Sometimes the client indeed wants to have a special layout in a page, but I think that can be best done by customizing the CMS so that it fits the client need.

Image/form to Pascal/Delphi code converter?

Does anyone knows about any editor allowing to visually design a form (by form I do not mean DFM or Delphi form, but a "paper form", like those pre-printed forms that you fill with some info) and that generates pascal commands to draw that form in a Printer (or Image) canvas?
What I want is an easy way to draw/design this form visually, composed just by lines and text, and a way to convert this to Pascal commands that when run, will draw that form in a Canvas (Image or Printer), respecting the original layout and scale, doesn't matter the Canvas DPI where it is being drawn.
Update: Maybe I wasn't clear enough about what I need and why I need it. I developed an Open Source component called TFreeBoleto (freeboleto.sf.net). It is used to generate and print bank billets (a common method for billing people in Brazil). Right now, the component uses a TBitmap image containing the "billet" mask, and TextOut methods for the dynamic areas (ie: billet number, customer name, etc). It is fine when looked in the screen, but some people complains that the quality of the printed image is not good. The component uses a BltTBitmapAsDib procedure to maximize the quality of printing, but some people still think it is not good enough. So, my idea was to avoid using a bitmap image as the form layout, and draw everything direct in the canvas (both form and printer). Check here for a sample of what a bank billet looks like.
Of course ReportBuilder and/or FastReport could solve the problem, but they are not free, so I cannot include it in the component. I need "native" solution that any standard Delphi install would be able to compile.
You might get what you want out of the Fast Reports Report Designer which is a commercial reporting system for Delphi. Remember that a report is just a page. That page can be shown on the screen or printed on the printer.
You also might find that something like TRichView helps you.
Whether using TRichView in particular or not, I would look into using HTML to do what you want. I would use HTML+CSS to do both a screen and printer layout, that can also be viewed on the web. For simple text layout plus text boxes I think even bare HTML and HTML tables might be sufficient. To visually design simple text pages, using a Delphi application, I would use TRichView.
In both cases, you would be creating documents, not code. To create code that creates a page, without using any document system, would be very difficult indeed, and I am not sure what you would really do with that code, since you would need a compiler or interpreter to convert that code into something that you could use. Please clarify what you mean by "creating code", and what syntax you would want that code to be using. If HTML is code in your definition of "code" then maybe HTML is the best kind of "code" for your problem.
I do my form-work with WPTools. It is also a commercial product. The core is a very good wordprocessor and form-designer. The engine can render text and forms to any canvas (screen, printer, also create pdf) and is highly flexible. Output is mainly rtf and html.
I also see no advantage in creating pascal code to redraw the form. What you need, i think, is a good WYSIWYG-editor which creates a document that fits your needs.
Check out ReportBuilder # http://www.digital-metaphors.com/
It is a commercial reporting tool for Delphi - around a long time, very high quality, with all native Delphi source code packaged with it. I am using it for an important commercial project right now and I recommend it highly (I'm not working for them.) I've used MANY Delphi reporting tools over the years and this one is the best IMO.
RBuilder also has extensive support for paper form emulation see:
http://www.digital-metaphors.com/products/report_design/form_emulation.html
I haven't worked with that feature, but you can download a full-featured demo and try it.
Yoy can use Adobe Acrobat (full version) to create forms.
Then you can use free Acrobat Reader to display and print forms or other COM object in your application.
I think it is best solution for you.
PS
All tools for reports that are included in Delphi are free for you to design form and are free to distribute if user only preview and print already designed reports.
The same is valid for Adobe Acrobat (you may distribute forms) but you have added that you need to print form and some text over form. Maybe it is easier if you use reports but it is possible to do the same using PDF.
Most report engines are not open source but are free to distribute. There is many components for creating PDF - paid (one time), free, as well as open source.
PPS
I have read your updete for second time. Since you are using TBitmap and you can to TextOut so: You can use TMetafile. There is many editors for metafiles and it is free to distribute metafiles.

Is it better to use #font-face or cufon rather than images?

I have a site that requires Trade Gothic. I'm wondering if it's better practice to use #font-face or cufon with a font that looks similar to Trade Gothic or just go the image route. Obviously, using images will look better but what is better practice? For example, is replacing header titles with images like below bad?
<h2><span>title here</span></h2>
span { display:none }
h2 { background:url(image.jpg);display:block;height:x;width:y }
It depends on the strictness of your requirement and browser support within your target audience, especially if you want to support mobile devices.
If using a similar-looking font is good enough, the requirement may really be a nice-to-have feature, so anything that degrades gracefully should work. #font-face seems the easiest to implement (just CSS and font files) and it doesn't require Flash or JavaScript (good for mobile users). Google Web Fonts is a great resource or you may even be able to create your own web font using a generator like this one.
You'll have to decide what works best for the majority of your audience and weigh in how flexible the requirement is. If you use a JavaScript-based solution and the audience has it disabled, is that a deal-breaker? Image replacement is not inherently bad, but it can be tedious to maintain if you have much content to worry about (especially if it also changes often).
I use both.
I like to use Cufon for navigation and/or main heading elements, because I think it renders better (specifically in Windows).
For any sub-headers and other text, I use #font-face, so that users may select the text.
I'm currently replacing header images with #font face, as they can load quicker, and text is always more SEO friendly, however you must be careful when doing this as this increases http requests which can then take longer to load. Also there are some legal issue as to which fonts can be used for web.
However it is especially ideal when no other font will do.
FYI browser support for #font face has been available since IE 4, as far as I know.
Well, the most obvious advantage that #font-face and cufon have against the image replacement method that you mention is that they generate your text dynamically and you don't have to create an image for each text that you want to replace.
Take a look here:
https://stackoverflow.com/questions/692990/sifr-vs-cufon-vs-typeface-js

What are some best practices to support multiple resolutions in a web application?

What are some best practices on enabling a web application to support multiple resolutions? Specifically resolutions that are wide-screen vs. normal aspect ratio.
It doesn't seem like there is an easy answer - other than simply supporting a few fixed resolutions and using some absolute positioning to get the layout to work correctly.
This of course gets even more difficult to make it cross browser.
Does anyone have any good resources of this problem?
You can always try to use a liquid layout structure where the width of your elements are scaled proportionate to how wide their browser window is.
here is a good article explaining different layouts including liquid layout.
http://www.maxdesign.com.au/presentation/liquid/
PS. the above mentioned site (maxdesign.com.au) is using liquid layout itself, so try and change the size of your browser when reading the article.
One fast, simple, fairly robust way is to use a framework like Blueprint or 960gs to lay out the site. They're browser-independent so you don't need to worry about that, and they make most column layouts pretty easy.
They both work on the idea of creating a fixed-size container somewhere between 900 and 1000 pixels wide for your content. Most people run in at least 1024x768 nowadays. If you need more width than that for your content, you're probably doing it wrong.
The one area where ~960px might not work is mobile phones... but that's what mobile stylesheets are for, right?
In Opera and Safari (esp. their mobile versions) you can use CSS3 media queries, which let you declare completely different styles for different screen resolutions.
This can be emulated in other browsers using Javascript – Alistapart: Switchy McLayout
You can use percentages to set width and heights also, but this is also difficult sometimes.
You have two options here:
Fixed Width Layout
Flow Layout
Both have benefits and drawbacks, and in the end, it's a design decision as to which is the best choice.

How do you feel about including ie7.js or ie8.js in your page?

See here: http://code.google.com/p/ie7-js/
Does anyone have any experience or remarks about this javascript? Is it worth including? Do you recommend it?
I know many people, myself included that are using various IE hacks to get transparent PNG support. THis looks like a little bit more help, and as long as it works, and the size is fairly small, I wouldn't see much against using it.
I've used it before, and my results are mixed. Those scripts cause IE to churn for a bit on page load. Basically, you have to think of it as iterating through Elements and stylesheet rules to apply "fixes" for areas that are deficient in that particular rendering engine. In some cases, depending on how complicated your markup or stylesheets are, that can take a bit of time and you will see the browser hang.
That said, if you can trade off that performance cost, you will save development time as you'll spend less time hacking around IE6 quirks; IE7/IE8 will provide enough missing functionality that you can avoid certain edge cases, can develop using standards better (min-width/min-height, multiple className selectors, etc.), and certain rendering issues will disappear.
However, if you just need 24-bit transparent PNG support, use a tool built for that. Including IE7/IE8.js for PNG support alone is like pounding in a nail with a tank. Use DD_belatedPNG for that.
It works, but its worth keeping in mind that ie7.js and ie8.js do much more than provide transparent PNG support. Even with the transparent PNG support, its worth keeping in mind that transparent background images cannot be tiled (repeated) using background-repeat or positioned using background-position. This hinders any ability to use CSS rollovers using background-position. I've only used it on one site I've done, and now that I'm updating the site I can't remove the ie8.js because if I do the entire website breaks layout in IE. I don't believe I'll be using it in the future, and instead rely on simple CSS hacks or simply allow my sites to "degrade gracefully" in IE6.
I know that there are some tools for fixing the transparent PNG problem which are more flexible than this. For instance, the jQuery plugin ifixpng2 will support background position, which ie7-js doesn't do.
As long as you are aware of exactly what it fixes, I would say go for it. I'm not sure about this lib exactly, but some libs get very expensive if you have a large DOM, as they tend to hook in HTC file base behaviors on EVERY DOM Element. This causes the dreaded "Loading x of y" status bar message to flash constantly on the initial load, and any newly generated DOM content.
well its beautiful and works grate way u can use cs3 features like li:hover. we did lost of project last time using ie8.js and it works great way.

Resources