I'd like to use a non-standard web font to improve the appearance of my HTML.
Is it preferable to embed a web font or use something like sifr?
My understanding is sifr is a flash-based viewer for vector fonts but I've been reluctant to try it because it seems somewhat complicated.
There does not seem to be a lot of encouraging talk about web font embedding (because of legal issues) so maybe sifr is more of a standard way to do this?
Any feedback would be appreciated. Thanks.
Web fonts are supported in Safari 3.1, the upcoming Firefox 3.5 and the upcoming Opera 10. Internet Explore has supported a (different) format since IE4.
At this point, the biggest problems with the implementation in Safari, Firefox and Opera is that they require you to upload the original font file to your web server. For many fonts, this would constitute a violation of the license you received from the type foundry. Therefore, web fonts right now are not an appropriate solution if the type foundry has not given you permission to use them. However, there are freely licensed fonts available.
This leaves us with roughly three other options: images, Flash, and JavaScript-based solutions. Images are often preferable in that they have minimal impact with regards to browser quirks and performance, however dynamic image generation in, say, PHP often does not look as good as other solutions. You could of course manually create images in Photoshop, but that would usually defeat the purpose.
sIFR uses Flash to render the text, and is quite flexible in that you can select the text, change it dynamically, and have some control over the styling of nested HTML elements. Hoefler & Frere-Jones has given sIFR the OK, provided you pay for a server license and take all possible measures in limiting the sIFR Flash movie to your domain name.
Cufón is a purely JavaScript solution that has implemented its own rendering engine, which is insanely clever. At this point its not as flexible as sIFR, and its legal issues are still unclear.
That said, images, sIFR and Cufón are all hacks, and we need proper web fonts yesterday.
(Disclaimer: I'm the lead developer of sIFR, so I might be somewhat biased.)
You could also consider the JS alternative(s). However, for best cross browser compatibility you're better off using images and perhaps a background-image and text-indent CSS trick to replace static text with your images.
The technique I mentioned above (and others) can be read here: http://css-tricks.com/nine-techniques-for-css-image-replacement/
Something to consider:
For every visitor who sees your 'better looking' fonts, there are just as many who won't due to having an incompatible browser or disabling that feature. Having just the right font probably isn't the most valuable design change you could work on.
Written from my mobile browser which doesn't do embedded fonts.
Note that CSS3 Web Fonts module, which defines font embedding is still a Working Draft. Indeed, the practical support of font embedding isn't good. I'd say it's better to wait another 2-3 years.
Also worth nothing: TypeKit, a service that gives you a line of JavaScript to abstract all of this away.
Related
I'd like to create a visually appealing select-dialog that shows FontAwesome-Icons and a word describing the symbol to select from various scales for statistical data.
So I'm using the FontAwesome-Fonts for the select-tag and the unicode-glyphs for the various symbols. That first part works nicely.
But the words I am using are also used in FonAwesome to form ligatures that can also be used to get the icons (I thought this was limited to the desktop-version, but as my example prooves, it also happens on the web). The FA-Site states that they are "...aren't comfortable considering ligatures for Web Fonts + CSS".
Please check out my fiddle here or the screenshot:
So, my questions are:
if it's not supposed to happen with Webfonts/CSS - is there anything that I am doing wrong using them? (Of course I have the desktop-fonts installed on my machine, I guess we won't know if users of the website will have them or not)
is there any way I can avoid the ligatures taking effect within the option-tag? (as you see in the sample, I am already using font-variant-ligatures: none; in the CSS)
I found a way to solve this by defining dedicated #font-faces with a different name. (My theory is that Chrome uses the local font I have installed and that it's ligatures override everything I do in CSS). That "special font-face" is sure not to be found locally...
If someone finds a better explanation or fix, I'll happily accept it.
This is a question and an answer :-)
For a long time now I tried using JQM with Hebrew. Getting the Hebrew letter is easy (utf-8 encoding...) , but the thing that didn't work was the alignment..
I mean switching the direction of the elements, the text alignment, positioning etc.
I found many questions about this, but few answers (and the ones I found didn't do a complete job).
Then I found this excellent article:
http://rtl-this.com/tutorial/rtling-hello-world-webpage-rtling
And I implemented it on the css file (more precisely on the one here: http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.css ).
That worked :-)
And if I'll figure out how to upload a file, I'll share :-)
I hope this will be useful.
You have to make changes to the JavaScript file as well to make sliders and flip switches work properly. Here is the full version of jQuery Mobile RTL I made.
I've recently tried to use jQuery mobile to develop an Arabic iOS application with RTL layout, and while jQuery Mobile doesn't support RTL yet, it wasn't too hard to hack the CSS to make it look and act like a proper RTL application.
But I ended up abandoning jQM altogether because, at least as of 1.0.1, the performance was simply unacceptable.
I tried a few hacks like removing all gradients (which helped a little) and disabling animation (which didn't), but it still took a good half a second for the UI to respond to user input.
I'm sure things will improve with the time, but for now at least jQuery Mobile is not an option for me. Its a shame too because it's declarative programming model is so deliciously easy to use.
There are about four implementations I can think of that are capable of loading SVG graphics into a Delphi application.
One of those, by Mattias Andersson, who is the author of FMX.Canvas.VPR
, works with FireMonkey, but he's not yet prepared to release the code.
A second one, by Martin Walter, works with the VCL, but developer has quit Delphi and has no plans to convert to FireMonkey.
A third one, part of the AGGPAS framework, works with the VCL, but no FireMonkey.
A fourth one is in development by Jason Southwell, but no date has been fixed yet.
So my question: what road to take if I want an SVG component today, without trying to reinvent the wheel a fifth (and probably more) time?
I'm Mattias Andersson -- the author of FMX.Canvas.VPR; I can say that I'm still actively working on the SVG solution. I guess once I have properly added support for gradients and text rendering then I can release a first beta version. I'm relying on TXMLDocument and that is a bit restrictive in what you are permitted to do (IMO), so I've had to invent some workarounds (maybe a better option would have been to implement my own XML class from scratch.) Also, I've had to do some run-time patching of the FireMonkey classes in order to make everything work correctly. The good part is that I'm actually implementing things according to the SVG interface specifications.
The SVG component I've been working on has been released as part of our Apesuite for Firemonkey.
http://arcana.sivv.com/apesuite
Getting involved with Mattias Andersson in the development is the best option:
FMX.Canvas.VPR by Mattias Andersson looks promising and VPR is proven to be an excellent project
No spoon-fed SVG FireMonkey component working out-of-the-box is available as of the time of posting (extensive web search made in general).
You could also consider using Chromiumembedded. Just load the svg in the embedded browser. You can then mix Delphi code with javascript, mix in html and css, etc.
This way, you can just leave it up to Chrome how to draw stuff fast (for example whether to employ gpu acceleration or not).
You'll get proper svg support, it's easy to integrate into your application, it's flexible, and there is lots of documentation and example code available online.
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.
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.