In my Delphi program I want to display some information generated by the application. Nothing fancy, just 2 columns of text with parts of words color-coded.
I think I basically have two options:
HTML in a TWebbrowser
RTF in a TRichEdit.
HTML is more standard, but seems to load slower, and I had to deal with The Annoying Click Sound.
Is RTF still a good alternative these days?
Note: The documents will be discarded after viewing.
I would vote for HTML.
I think it is more future oriented. The speed would not concern me.
The question of HTML or RTF may be irrelevant. If they are just used for display purposes, then the file format doesn't matter. It's really just an internal representation. (Are any files even being saved to disk?) I think the question to ask is which one solves the problem with the least amount of work.
I would be slightly concerned that the browser control is changing all the time. I doubt the richedit control will change much. I would lean towards the richedit control because I think there is less that could go wrong with it. But it's probably not a big deal either way.
Have you considered doing an ownerdraw TListView?
I'd also use HTML. Besides, you just got an answer for the clicking sound in TWebBrowser.
If you'd rather not use TWebBrowser, take a look at Dave Baldwin's free HTML Display Components.
I would vote for HTML, too.
We started an app a while ago...
We wanted to
display some information generated by the application. Nothing fancy, just...
(do you hear the bells ring???)
Then we wanted to display more information and style it even more....
...someone decided, that RTF isn't enough anymore, but for backwards compatibility we moved on to MS Word over OLE-Server. That was the end of talking about performance anymore.
I think if we would have done that in HTML it would be much faster now.
RTF is much easier to deal with, as the TRichEdit control is part of every single Windows installation, and has much less overhead than TWebBrowser (which is basically embedding an ActiveX version of Internet Explorer into your app).
TRichEdit is also much easier to use to programmatically add text and formatting. Using the SelStart and SelLength, along with the text Attributes, makes adding bolding and italics, setting different fonts, etc. simple. And, as Re0sless said, TRichEdit can easily be printed while TWebBrowser makes it more complicated to do so.
I would vote RTF as I dont like the fact TWebBrowser uses Internet explorer, as we have had trouble with this in the past on tightly locked down computers.
Also TRichEdit has a print method build in, where as you have to do all sorts of messing about to get the TWebBrowser to print.
Nobody seems to have mentioned a reporting component yet. Yes, it is overkill right now, but if you use it anyway (and maybe you already have got some reporting to do in your app, so the component is already included) you can just display the preview and allow to print / export to pdf later, if it makes any sense. Also if you later decide that you want to have a fancier display there is nothing holding you back.
If both HTML and RTF won't satisfy your need, you could also use an open source text/edit component that supports coloring words or create your own edit component based on a Delphi component.
Another alternative to the HTML browser is the "Embedded Web Browser" components which I used a few projects for displaying html documents to the user. You have complete control over the embedded browser, and I don't recall any clicks when a page is loaded.
I vote for HTML also
RTF is good only for its editor, else then you'd better go standard.
RTF offers some useful text editing options like horizontal tabulator which are not available in HTML. Automatic hyperlink detection is also a nice extra. But I think I would prefer HTML, if these features are not required.
I vote for HTML.
Easier to generate programmatically.
Widely supported.
Since you don't need WYSIWYG capabilities I think HTML advantages trump RTF. Moreover, should the need to export generated data for further, WP-like editing arise, remember that major word processor can open and convert HTML files.
Use HTML, but with 'Delphi Wrapper for Chromium Embedded' by Henri Gourvest , Chromium embedded uses the core that powers Google Chrome.
Don't use TWebBrowser, I'm suffering from all programs that use IE's web control - the font is too small on my 22' monitor with a 1920x1080 resolution, I use Windows 7 and my system's DPI is 150% (XP mode), I tried everything to tweak trying to fix that, no luck...
Related
We are having Multiple PDF which have account tables and balance sheet within it. We have tried many Converters but the result is not satisfactory. Can anybody please suggest any good converter that would replicated the contents of PDF to Exact structure in HTML. IF any paid Converter is there please suggest me .
This is the PDF we want to convert and Show in html "http://www.marico.com/html/investor/pdf/Quarterly_Updates/Consolidated%20Financial%20Results%20-%20Q3FY11.pdf"
Have you looked into this? http://pdftohtml.sourceforge.net/
It's open source as well, so it's free and can be modified if necessary.
There's even a demo showing the before PDF and the after HTML version. Not bad if you ask me.
If you're having issues specifically with tables in PDFs, perhaps the issue are the table themselves and whatever program is being used to generate them. Not all PDFs are created equal.
ALSO: Be aware that all PDFs that I've created and come across over the years have had lots of issues when it comes to copy/pasting blocks/lines of text that have other blocks/lines of text at equal or higher height on any given page. I think Acrobat lacks the ability to define a "sequence order" of what block is selected after what (or most programs don't use it properly), so the system sorta moves from a top-down, left-to-right way of selecting content.....even if that means jumping over large blank areas or grabbing lines from multiple columns at once when you wouldn't expect it. This may be part of your tabular data issue. Your weak link here is the PDF format itself and I think perhaps you may be expecting too much from it. Turning anything into a PDF is pretty much a one-way street, especially when you start putting lots of editable text into it.
Have you tried http://www.jpedal.org/html_index.php - there is also a free online version
It seems the most common aproach to web design is to use HTML/XHTML & CSS in conjunction with other technologies or languages like Javascript or PHP.
On a theoretical level, I'm interested to know what other languages or technologies could be used to build an entire site without using a single HTML tag or CSS style for styling/positioning?
Could a website be made only using XML or PHP alone, including actual styling and positioning?
Presumably Flash sites are till embedded in HTML tags?
Thanks
There are actually several solutions that allow you to nearly completely avoid CSS and HTML.
GWT: Google Web Toolkit
Written in Java and will allow you to build both server and client code in Java. Used to build Google Wave.
Cappuccino and Objective-J:
Objective-J is to JavaScript as Objective-C is to C. It extends JavaScript with many near features, including type-checking, classes and types.
Cappuccino is like Cacoa (Mac OS X GUI toolkit).
Using these two you can build incredibly rich and desktop like webapps. They run mostly on the client side and you can use whatever you want on the server.
A good example is 280slides
SproutCore is similar to Cappuccino, but it uses pure JavaScript instead. Apple is using SproutCore to make me.com.
I should also mention that knowledge to HTML, CSS, JavaScript is a good skill to know, just like understanding your compiler is a good skill.
EDIT:
As said above Adobe Flash can also be used.
You can make a website with out a single html tag. Just give folder read access to all your directories, have sensible file names. From here you user will be able to browse images , read text files, download videos and depending on the content he may or may not come back ever again, but you do achieve the goal of setting up a "website" with out a single line of html or css or any other code for that matter.
:-) :-) :-)
You can host a telnet server with anonymous access and a specialized shell that restricts the user to doing whatever it is you want the site to do. ;)
Lets make the distinction between what is required by the web browser, and what you as a developer use to create that markup.
Remember that HTML nowadays is xml. You could use any markup language you like and convert that to HTML using XML.
eg ASP.NET uses markup such as which is converted on the server to .
As long as the content going down the wire to the browser is HTML, or generates HTML through script, you can use any approach you like.
However these approaches have mostly failed as developers prefer having direct control over the markup. It makes css as well as scripting much easier when you are certain what the html is going to be.
ASP.NET MVC is a product created in response to criticisms leveled at the ASP.NET webforms model.
Also, this is another answer because it's a completely different technology, but you can write an application in XUL and it'll run in Mozilla-based browsers without any HTML.
There's also XML. You can create websites with XML only. A well known one is World Of Warcraft. Check the page source. An XSL is used as stylesheet. There exist even XML based web frameworks like OpenLaszlo. You can let it serve either DHTML or Flash on reqeust out of a single XML template.
The Wt C++ Web Toolkit.
You can write your web application in C++ using Qt-style widgets (input boxes, buttons, tabs etc) and hook up client-side events to C++ code on your server. All without writing any HTML or CSS.
A sample application from their website (you may also want to look at this excellent tutorial):
HelloApplication::HelloApplication(const WEnvironment& env)
: WApplication(env)
{
setTitle("Hello world"); // application title
root()->addWidget(new WText("Your name, please ? ")); // show some text
nameEdit_ = new WLineEdit(root()); // allow text input
nameEdit_->setFocus(); // give focus
WPushButton *b = new WPushButton("Greet me.", root()); // create a button
b->setMargin(5, Left); // add 5 pixels margin
root()->addWidget(new WBreak()); // insert a line break
greeting_ = new WText(root()); // empty text
/* when the button is clicked, call the 'greet' method */
b->clicked().connect(this, &HelloApplication::greet);
}
void HelloApplication::greet()
{
/* set the empty text object greeting_ to greet the name entered */
greeting_->setText("Hello there, " + nameEdit_->text());
}
Curl (requires a browser plugin)
Wikipedia article
A webpage looks like this:
{curl 1.7 applet}
{value
let b:int=99
let song:VBox={VBox}
{while b > 0 do
{song.add b & " bottle(s) of beer on the wall,"}
{song.add b & " bottle(s) of beer."}
{song.add "Take one down, pass it around,"}
set b = b - 1
{song.add b & " bottle(s) of beer on the wall."}
}
song
}
Source
Since browsers view HTML, I'm assuming you mean create a site without ever having to edit/write HTML/CSS. The framework/app environment/whatever taking care of everything for you - yet still allowing you control over the presentation layer.
Seems like that is certainly possible on a theoretical level.
I ran across Noloh (not one line of html) a while back. Was intrigued, but never actually tried it out.
From various places on the Noloh site:
Because NOLOH does not rely on HTML or pages, maintaining complex rich Internet applications is significantly easier than with other methods.
Developing applications with NOLOH only requires using a single, unified language: a superset of PHP that completely maintains all aspects of server-client communication for you!
I think you could build a site entirely in SVG.
The front page of emacsformacosx is almost entirely SVG, for example.
Downsides: It wouldn't be viewable in IE (at least through version 8). And last I looked, text support, like flowing and justification, was weaker in SVG. (You could embed HTML inside an SVG element when you needed sophisticated text features, but that would violate your no-HTML rule.)
You'd probably still want to use CSS with SVG, because it's a good idea there for the same reason it's a good idea with HTML, but it wouldn't be necessary.
A website is always viewed through a browser (at least always if you are human :)). Browsers understand HTML. Whatever the technology - you have to basically render HTML. Even in cases with rich technologies like flash, the flash object that is rendered by a browser plugin is embedded inside the HTML.
In theory it is possible to do it without HTML, but the question becomes how much does the product diverge from the definition of a website...
One really short, simple answer... you can't :D
Flash requires an embed tag, an image requires an embed tag etc, so you'd have to use HTML in some method or another.
PHP is an embedded language, it is used to generate HTML on which the browsers renders, with XML, well technically a browser like Ie or FireFox will render it in it's own way for readability, but I would not class that as a website.
The major developments in the world of web technologies involves the development of HTML and CSS to improve them, there isn't any need for an alternative. In fact we're pushing towards a standard, what point would there be in introducing a new language to negate these standards. The whole IE saga would simply get worse.
Like the others have suggested, you could directly load an image or a flash file, but an image is useless on it's own, and a flash interface throws up loads of problems like SEO, accessibility etc, not least it's very heavy and usually completely misused. In my mind I wouldn't even class this method as a website, it just doesn't tick any of the boxes (IMO).
I think you can have an URL pointing directly at a hosted Flash (SWF) file, I've certainly done this though I don't know if all browsers work.
Anyhow, I tested this when developing MyDinos.
e.g: http://mydinos.com/home.swf
You can use Emscripten and its SDL subset.
You could try using quickstatic. You can code HTML templates from Python3. What is super cool about it is the fact that if you put in a for-loop for a certain item, you can generate that many items (maybe even use it to print items from a directory or quickly serve thousands of links).
I have a report I need to print out in an application I'm usually doing maintenance for. My question, which interests me beyond the scope of this task is, what are the ways to format an HTML page for printing? What are the pros and cons of each?
Note that the page is meant only to be printed. I'm not asking about an HTML page that looks ok also when printed.
Generally speaking, I know I can either rely heavily on <table>s or on <div>s, but I don't know which way to go.
I would also appreciate some resources to get me started, or to help with known problems, in any method you suggest.
Thanks,
Asaf
As you can certainly see, printing and web presentation are two different creatures. The main issue is the bounds of the printed page, which does not exist in a web page. Even if you think you have a page laid out in a manner that will fit a printed page, then you need to deal with the fact that the font you are using may not work or scale correctly on the user's printer.
I know of three ways to deal with this issue:
Use fixed-sized fonts (like Courier), limit yourself to an 80 column width, and only use font characters: meaning use something like asterisks for borders, etc. This is VERY old school - your reports look simple and old and plain. But, they will always print they way you intended.
Convert your report to an image. Images can be made to confirm to a specific size which can fit on a page. However, you can still have issues due to printer margin settings.
Let another application do the work for you. What I mean by this is put your report into a PDF or a spreadsheet. Both PHP and Perl have easy to use modules for creating a PDF - with no licensing needed. Perl has a fantastic spreadsheet module. This route takes a little learning up front, but frees you from having to be an expert on printing (which can be a real pain).
In case you DO want to have a page that also looks good when viewed in a browser, consider multiple stylesheets for different medias.
One business goal requires that I make a form on screen that's pixel-perfect. If a user prints this form, it will exactly match the US Government Printing Office version of the form; the printer will produce a (reasonably) scannable copy of this document. The previous solution is PDF, which will only work to a certain point for us.
I'm leaning towards HTML/CSS, and would like suggestions on tools to assist that.
For tools, PixelPerfect in Firefox seems a good start. The target platform for this is (drum roll) IE6, if it helps. The document looks like this.
If HTML/CSS is a complete no-go, Adobe Flex is my next choice.
If pixel perfect printing is the goal, and not even PDF will get you there, you can pretty much give up straight away on printing from the browser. There are waaaay too many variables when rendering on the client side: from different browsers (IE6? Good luck!) to different fonts, to user settings, to A4 vs Letter size paper.
Could I ask why PDF doesn't suit?
I agree that pixel-perfect layouts are very, very hard to achieve with html/css, particularly with forms. However, I think pdfs can recieve input from external web forms, or have textfields that when filled out will print.
Flex outputting to pdf would be a good idea, but I don't think using flex as an rendering engine will help too much with this.
Another option would be to make the pdf and use a server-side langage to customize it with fields from a prior webform, and output the result. (Can easily be done with ruby/django/php, there are some good pdf libraries out there.)
First, abandon pixels. What you're looking for is a print stylesheet, with everything specified using physical units (cm/inches), font size in pt, etc. What is displayed on the screen, in what font size, and whether it is pixel-perfect or not doesn't seem relevant to your requirement of producing a scannable copy.
The question is now, is IE6 support for physical units and print stylesheets complete enough for that? Given my experience with making print stylesheets for clients, where IE would simply crash during the print process if you looked at it wrong, I'd say not too likely -- not with the complexity of the forms you're dealing with.
If you're worried about the renderer (IE, Acrobat, etc.) screwing up, you could always render the form on the server, and just serve an image to the user.
Dean, check out Prince. Bert Bos and Håkon Wium Lie used it for production of their book on CSS. They explain a bit about it in an A List Apart article.
Basically, something better than this:
<input type="file" name="myfile" size="50">
First of all, the browse button looks different on every browser. Unlike the submit button on a form, you have to come up with some hack-y way to style it.
Secondly, there's no progress indicator showing you how much of the file has uploaded. You usually have to implement some kind of client-side way to disable multiple submits (e.g. change the submit button to a disabled button showing "Form submitting... please wait.") or flash a giant warning.
Are there any good solutions to this that don't use Flash or Java?
Yaakov: That product looks to be exactly what I'm looking for, but the cost is $1000 and its specifically for ASP.NET. Are there any open source projects that cover the same or similar functionality?
File upload boxes is where we're currently at if you don't want to involve other technologies like Flash, Java or ActiveX.
With plain HTML you are pretty much limited to the experience you've described (no progress bar, double submits, etc). If you are willing to use some javascript, you can solve some of the problems by giving feedback that the upload is in progress and even showing the upload progress (it is a hack because you shouldn't have to do a full round-trip to the server and back, but at least it works).
If you are willing to use Flash (which is available pretty much anywhere and on many platforms), you can overcome pretty much all of these problems. A quick googling turned up two such components, both of them free and open source. I never used any of them, but they look good. BTW, Flash isn't without its problems either, for example when using the multi-file uploader for slide share, the browser kept constantly crashing on me :-(
Probably the best solution currently is to detect dynamically if the user has Flash, and if it's the case, give her the flash version of the uploader, while still making it possible to choose the basic HTML one.
HTH
You could have a look at the Fancy Upload script. Though it uses flash it still looks great.
The problem here is that the browsers specifically work to block anything that changes the basic file upload input control. You can't change it with javascript for instance.
The reason is security - if I could script it I could build a page that when you visited it sent me various files from your hard disk. Not nice.
There are various workarounds at the moment, but they're different between IE and FX (I don't know about Safari, Opera, etc).
Look at what http://www.gmail.com does in IE and FX when you attach something to an e-mail.
I want to see that rubbish "Browse" button - it tells me that I'm not letting anything unexpected in.
It is true, the file upload control is definitely behind the times. Hopefully this will be addressed in a future asp.net version.
Though it costs some money, I have found the Telerik upload control to have all of the functionality that you are looking for, including styling and progress updates (it also optimizes memory for large uploads).