My app uses a custom font (by Linotype, i.e. a professional font). In UILabels as well as UITextViews and TextFields, composite glyphs like the German ö, ä and ü are rendered in incorrect size and weight.
I tried quite a lot from changing trying other fonts (which rendered as expected) to testing other font sizes, but always had this artifact.
Does anybody have a clue, what the problem with that font could be?
As a sidenote, the android app renders that same font just fine, which only hints that font rendering engines on the two platforms are likely different.
Here is an example (check the the ü-glyph):
I spent a lot of time trying to figure out the cause, but ignored the obvious: the string literal in the strings resource file was copied from another application (or a pdf I guess) and contained the composed characters in a kind of alternative way.
After retyping the text, which which contained odd characters, they were rendered perfectly fine!
I know it looks like I only wrote the question to answer it myself, but it is just a happy incident that I found the cause just now while going on examining the problem.
Related
I have a website that is using Angular material. I like elements and everything except default font sizes and elements are huge. To see website in acceptable scale me or my users have to zoom out at least 75% on the desktop and majority of my users are desktop users. Is there a way to specify in angular material to use smaller fonts, elements, etc?
in your main css file
add following
html {
font-size: 62.5% // adjust the size with percentage here.
}
and i recommend using em and rem for font-sizing
let me know if it didn't worked, i might provide another solution
Before you attempt anything, make sure you are using the correct fonts and font sizes by following the typography guide.
Font sizes can be adjusted by customizing the typography. Changing the size of elements is technically possible, but to do it you would need to override the styles for every Angular Material component - so it is highly impractical.
Also, component sizes as well as font sizes are determined by the Material Design specifications, so changing things means you are no longer properly following the specification, and IMO you would end up with a bad looking web site (at least bad looking in terms of following Material Design).
There is a weird behaviour in iOS Safari where a specific font-weight of 900 for Avenir font produces an extra space on the right of characters fi.
I tried using 'Avenir Heavy' which corresponds to that font-weight but the issue is is still apparent. It does not appear on any other font-weights though, just on that 900 weight. I tried playing around -webkit-font-kerning, -webkit-font-smoothing, letter-spacing, but none solves the issue.
Is there a CSS-only way of working around this? Or is this an issue on the font/browser itself?
Thanks.
I was running into the same issue, but with font weight 400 on iOS Safari. I was able to identify a workaround that hopefully generalizes to others with the same situation. By adding the following CSS :
text-rendering: optimizeSpeed;
This disables kerning and ligatures, and likely the spacing irregularity after "fi" is a kerning issue (potentially specific to the font file, but that is beyond my knowledge).
I am using the most excellent PHP library ePub to on-the-fly create digital books from HTML stored in my database.
As these are part of a collection, I am including a cover image for every book. Everything works fine in the code but depending upon the device/software interpreting the ePub, the image may get cut off. I have seen 600x800 pixels as a recommended size, but it still cuts it off (for example in Aldiko in Android). Is there a standard size that is recommended in the documentation?
Honestly, I would love a good and readable recommendation for documentation of the ePub format.
So, it seems that Aldiko has the problem, and not the other e-Readers I have tested (Calibre, Overdrive).
After trying various ratios, I found that Aldiko only respects the height:100% style I have called out in the height direction. It doesn't scale the image, only sets the height at 100% of the screen width. I am going to have to go with this being a bug in Aldiko, and keep the recommended 600x800 ratio for maximum resolution.
Another interesting thing I discovered as well; the Aldiko reader didn't recover as well from non-standard HTML. On one of the database entries, a <style> tag inside the <body> disappeared, but the style text did not. This is not the same for the other e-Readers.
The best general advice I found on the internet is Preparing Images for Ebooks Project (PIFEP).
Is it possible to generate a specific
set of font from the below given image
?
My idea is to generate a specific font
for the below given image of text ,by
manually selecting portion of the
image and mapping it to a set of
letter's.Generate the font for this
and then use this font to make it
readable for an OCR.Is generation of
font possible using any open-source
implementation ? Also please suggest
any good OCR's.
Abbyy FineReader 10 gets better than expected results but predictably gets confused when the characters touch.
Your problem is that the line spacing is too small. The descenders of each line overlap the character bounding boxes of the characters in the line directly below. This makes character segmentation almost impossible because the characters are touching and overlapping. The number of combinations of overlapping characters is virtually impossible to train for. The 'g' and 'y' characters are the worst offenders.
A double line spaced version of this would probably OCR reasonably well.
A custom solution that segmented and separated the each line along with a good dictionary would definitely improve the results. There would still be some errors to correct manually though. The custom routine would have to deal with the ascenders and descenders and try and segment the image into lines which can then be fed to a decent OCR engine. One way would be to analyse every character blob on the page and allocate it to a line. Leptonica (www.leptonica.com - C Imaging Library) would probably make this job a little easier.
I would not try this without increasing the resolution to 200 or 300 dpi first.
With this custom solution, training a font becomes an option if the OCR engine does a poor job initially.
Abbyy (www.abbyy.com) or Google Tesseract OCR 3.00 would be a good place to start.
No guarantees as to whether all of this will work though. This is quite a difficult page to OCR and you need to work out whether it is better to have it typed up manually overseas. It depends on the number of pages to need to process.
I have to extend an OpenGL-Rendering system to support international characters (especially Hebrew, Arabic and cyrillic).
Development platform is Windows(XP|Vista|7), alas using Embercardero Delphi 2010.
I currently use wglOutLineFont(...) to build my font's display list and glCallLists(length(m_Text), UNSIGNED_SHORT, PWchar(m_Text) ) to render my strings.
While this is feasible for Latin-1 Characters, building the full Unicode character set in advance is pretty time-consuming (about 8.5 minutes on my machine), so I am looking for a more efficient solution. I thought about limiting the range from u+0020 - u+077f (Latin, Greek, Cyrillic, Arabic and Hebrew) to include just the glyphs I need, but that would just be a solution for my current needs, and will become insufficient once other encoding is needed.
On the upside, I do not have to worry about left-to right or right-to left direction as our application can handle this already.
I would expect this to be a well-known problem, so I would like to ask if there is any reference material on this on the web, or if you could share some insight on this?
Edit
A clarification: I use a polygonal font representations. Each Font is constructed at unit size (1.0) in advance and scaled appropriately using glScalef(...) before rendering. I did decide against pre-rasterizing since the users might zoom in quite closely (The application is used for CAD), so rastering artifacts would become visible.
Additionally, since a scene seldom exceeds more then a few hundred characters (mainly labels and measurements), the speed gain from pre-rasterization is negligible.
Don't pre-build the display lists :- create an intermediate sprite that builds the lists on demand, and caches them. Trying to pre-compute lists - or pre generate rasterized textures at every font size, font face, and for all characters, is impractical, Especially when you scale to far eastern character sets.
You need to replace the wglOutLineFont.
To do that, generate/render to texture the required glyphs using the wglOutLineFont, and then save the texture into a raster image file. Once application loads, it needs to load the texture image and the glyph texture coordinates (4 coords for each glyph), and to generate the display lists (one list for each glyph, each display list shall draw a single glyph as textured quad).
Each short representing a glyph shall have a corresponding display list (their value much match, and glListBase can aid in this).
I suppose loading a texture is faster than generating font display lists at runtime. Pratically you move offline the glyph raster computation. But the display list generation can be heavy (many glyphs). Indeed you can run in a separated thread the display list generation or generate only the display lists required by your needs.
I've had good luck transliterating this tutorial into C++, though I'm not sure how well it will transfer to Delphi.