webfont displayed screwy on pc - cross-platform

Wondering if anyone has come across this before. The first image is how it displays on MS platforms and is incorrect, the 2nd is how it displays on apple and is correct.
Thanks, for any help!

Font rendering differs across webbrowsers and platforms. There are many ways to specifically target those different enviroments.
Looking at the images it seems that the aliasing gives a less 'thight' result for this font at the size. You could try a slightly different size in your MS enviroment for better results.

Related

Multiple resolutions on Windows Phone 8.1

I'm moving to WP8.1 and there are different resolutions to be supported so I need to create the correct resources for each scaling factor.
Following this guide I've found out that I can use a simple naming conventions and the appropriate image will be automatically loaded without having to manage it from code.
What the guide doesn't say, and I can't seem to find it anywhere, is what the original size should be.
I need to know which one is the resolution that corresponds to the 100 scaling factor so that I can calculate the size of the scaled images.
Do you have any idea on this?
There's a lot of documentation for Windows Store (I'm not using Silverlight) apps but everything seems always related to desktop/tablets even if there's the phone icon.
Please refer section "1.a.i" as guideline (http://msdn.microsoft.com/library/windows/apps/xaml/hh965325.aspx) mention by you.
You need to create image with 96 DPI, considering as 100% scale.
I also recommended refer guidelines provided in this link http://msdn.microsoft.com/en-US/library/windows/apps/xaml/hh465362.aspx. Refer below statement from provided link.
"Windows Runtime apps (that run on Windows, Windows Phone, or both)
are automatically scaled by the system to ensure consistent
readability and functionality regardless of a screen's pixel density."
And also below one.
"Windows determines which scaling plateau to use based on the physical
screen size, the screen resolution, the DPI of the screen, and form
factor."
Hope this helps.

should i make different images for each folder in an android application?(hdpi,mdpi,ldpi)

I want to develop a game but I'm not sure about the sizes of the pics.
I checked the app after I finished one animation on my phone and on my emulator; the pics changed their size by themselves. Then should i make the same pic with different size for each folder on one pic with the same size and put it in each of the folders.
thanks!
You don't have to, but it can be useful: sometimes it's better to use a simpler image at small resolutions, and that's where the different densities are helpful.
It also allows more fine-grained control of scaling: if you only provide a hdpi version, a lot of detail can be lost if it has to scale that image significantly. By providing a ldpi version, you can provide a clean base picture which won't need to be scaled as much; resulting in fewer potential scaling artifacts (but unless the other versions are cleaned up a bit, you probably won't see much of a difference in the end).

Screen Resolutions

I am testing an application and need to test it with different screen resolutions with windows form applications.
What is the common resolution tested for now days?
That depends a great deal on your market/target audience.
I think your safe minimum 1024x768 for desktop apps but don't forget that mini PCs are taking off and they have smaller screens than traditional. If you're gonna run on one of these you need to consider "funkier" resolutions as well.
As far as maximum resolutions... the sky's the limit. Though i think if you look good in 1280x1024 you'll be fine in anything larger too.
This will depend on how the Windows forms is laid out, in relation to aspect size and resolution, the fonts used. Before when I developed WinForms applications, I used to rigidly stick to the minimum size of resolution 640 x 480, knowing and having the confidence that it will be fine in resolutions higher then that.
Sadly as it seems, it would make the form look a tad small when under a resolution such as 1,024 x 768!
This is something you need to be aware of.
Another angle of looking at is this - internationalization, yes that flaming international lingo for each label, this could disrupt the flow and layout of the winform itself, suppose you used a label that had a common word such as:
+-----------+
|First name |
+-----------+
Now, suppose this was translated to German (via babelfish.yahoo.com) for an example that label would be
+--------+
|Vorname |
+--------+
Wait! It gets smaller in Spanish (again via babelfish.yahoo.com)
+-------+
|Nombre |
+-------+
Yes, the label has shrunk and the end result, there could be potential gaps or labels flowing into one another because of the internationalization.
Sure, is'nt it great that we all have big fancy screens with resolutions up to 1,920 x 1,0768, on flat 24" screens, but even more so, the readability of the winforms can vary as well depending on whether ClearType is used or not! Even netbooks have a resolution of 1,024 x 600...
This is an interesting question that can underhandedly open up a can of worms as to BEWARE! Ok, I know I made it sound like as if internationalization was the big point behind it, you just do not know until you ask yourself and your superiors, who is the audience and what scope?
You will also earn bonus points if you target accessibility as well, big fonts, small fonts, how are the fields laid out, there is no hard or fast rules involved in this, it would be beneficial to do a small amount of research. Sure, it would be darn handy to drop on a component that will automatically resize the layout of the form scaling upwards for different resolutions, but what about the potential for internationalization...?
Good question worthy of a +1 from me!
That depends entirely on your application. For the last kiosk application I coded, the resolution was part of the specification, and was set to 1280x1024. If you're making a game, you'll need to support a wide range of resolutions, both fullscreen and windowed.
You will also want to take aspect ratio's into account (ie: wide vs. normal, etc.).
I usually design my windows forms, so that when you resize the form, everything resizes correctly. This usually means setting a reasonable minimum size for the form. I find that this works better than designing for 1 specific resolution.
Web users:
http://www.w3schools.com/browsers/browsers_display.asp
http://www.screen-resolution.com/common-screen-resolutions.php
See Google Browser Size.
Edited to add: That labs feature may be going away, to be added to Google Analytics.

Optimal image size for browser rendering

The question
Is there a known benchmark or theoretical substantiation on the optimal (rendering speed wise) image size?
A little background
The problem is as follows: I have a collection of very large images, thousands of pixels wide in each dimension. These should be presented to the user and manipulated somehow. In order to improve performance of my web app, I need to slice them. And here is where my question arises: what should be the dimensions of these slices?
You can only find out by testing, every browser will have different performance parameters and your user base may have anything from a mobile phone to a 16-core Xeon desktop. The larger determining factor may actually be the network performance in loading new tiles which is completely dependent upon how you are hosting and who your users are.
As the others already said, you can save a lot of research by duplicating the sizes already used by similar projects: Google Maps, Bing Maps, any other mapping system, not forgetting some of the gigapixel projects like gigapan.
It's hard to give a definitive dimension, but I successfully used 256x256 tiles.
This is also the size used by Microsoft Deep Zoom technology.
In absence of any other suggestions, I'd just use whatever Google Maps is using. I'd imagine they would have done such tests.

How to give best chance of success to an OCR software?

I am using Tesseract OCR (via pytesser) and PIL (Python Image Library) for automated test of an application.
I am checking that the displayed text is ok by making a screenshot and getting the text thanks to tesseract.
I had some issues in the beginning and it seems to work better since I have increased the size of the screenshot thanks to the bicubic interpolation of PIL.
Unfortunatelly, I still have some mistakes like confusion between '0' and 'O'. I can imagine that I will have other similar issues in the future.
I would like to know if there are some techniques to prepare an image in order to help the OCR. Any idea is welcomed.
Thanks in advance
Shameless plug and disclaimer: my company packages Tesseract for use in .NET
Tesseract is an OK OCR engine. It can miss a lot and gets readily confused by non-text. The best thing you can do for it is to make sure it gets text only. The next best thing is to give it something sanely binarized (adaptive or dynamic threshold to get there) or grayscale and let it try to do binarization.
Train tesseract to recognize your font
Make image extra clean and with enough free space around characters
Profit :)
Here are few real world examples.
First image is original image (croped power meter numbers)
Second image is slightly cleaned up image in GIMP, around 50% OCR accuracy in tesseract
Third image is completely cleaned image - 100% OCR recognized without any training!
Even under the best conditions OCR variants will sneak up on you. Your best option will be to design your tests to be aware of them.
For distinguishing between 0 and O, one simple solution is to choose a font that distinguishes between both (eg: 0 has a dash or dot in its middle). Would that be acceptable in your application?
Another solution is to apply a dictionary-based step after the character-by-character analysis of the text - feeding the recognized text into some form of spell-checker or validator to differentiate between difficult characters.
For instance, a round symbol followed by other numbers is most likely to be a zero, while the same symbol followed by letters is most likely to be a capital o. It's a trivial example, but it shows how context is necessary to make a more reliable OCR system.