In my project i use GhostScript to convert pdf file to png image. The problem is that it cannot process the font that not emmbeded in pdf file correctly, thus output was wrong. When using pdftoppm (an xpdf tool) the problem was fixed. So i want to know what is the diffence between ghostscript and xpdf in converting phase? Why does GhostScript need to use font but Xpdf doesnt?
Without seeing the PDF file its impossible to tell for certain but there are three possibilities I can think of;
1) The PDF file does contain the font and for some reason Ghostscript can't find or use it. That would be a bug, probably fixed by using the current version. If that doesn't fix it then you should submit a bug report.
2) You have the font available on your Operating System and xpdf has been told where to find it. If this is the case you can almost certainly give Ghostscript the same information via either FontConfig (on Linux) or by editing one of fontmap.GS or cidfmap, depending on the nature of the font.
3) xpdf isn't using the correct font either, but it just so happens that, by good fortune, the font it uses as a substitute is closer to the original font than the font Ghostscript uses as a substitute. As with 2 above you can change what Ghostscript is using.
This is, of course, why all PDF files should embed the fonts they use (as subsets at least), especially all the CIDFonts they use.
Related
I have a scanned pdf and I want to transform it to an editable text format. Do you have some recommendations to do this on Windows? I was thinking about using Linux as a subprogram of Windows. Any other ideas?
It looks like you work in Python, so a pypi package you might want to look into is pypdfocr. Essentially you'll want to use a tool like poppler to render the pdf and get the images from it (a scanned PDF is built on images), then read the text from the images via an OCR solution to get the text.
I have not used this package myself, so this is as much help as I can give. It should work with python in both Windows and Linux.
My project should display graphic overlay on the monitor using opengles2 in linux environment.
Need to display a text in different fonts on the monitor using opengles2. Freetype library can be used for rendering text in different fonts,
But I am not able to find an example program that would use freetype library in opengles2 Linux to render a text in different fonts.
I wouldn't use plain freetype on anything nowadays. It is missing so many opentype/unicode smarts which have been moved to other libraries a long time ago. So it will work on simple latin text, and hit problems on pretty much anything else (including not simple latin text).
You'd properly be better of long term taking a higher-level lib that abstracts all the text bits (freetype, fontconfig, harfbuzz, freebid, etc), such as pango cairo, and plug it on opengl es.
Some links:
https://dthompson.us/font-rendering-in-opengl-with-pango-and-cairo.html
http://emblemparade.net/blog/using-cairo-with-opengl-es/
http://cairographics.org/OpenGL/
Does anyone have any pointers where I can find extra information on how to create an opentype wrapper around a CFF font?
Currently I have a parser for CFF files so I can get all sorts of information out of it (cmap, glyph names, widths, names etc etc). Given this information I am unable to create an Opentype (truetype format like) wrapper so I can use the font on Windows using GDI; GDI will not load the Opentype font and the only thing I know is that it fails to load the font.
Does anyone know any additional information, validation applications, example code, get additional information why the font does not load from Windows etc etc?
Note: I am looking for information how to do it, not utilities and/or conversion tools.
Until now, I found three libraries you could reference:
FreeType: mainly in the cff package. Its main entry is cff\cffload.c. The library is now on GitHub.
FontForge: fontforge\parsettf.c, still on sf.net.
fonttools: fonttools\cffLib.py, on GitHub.
ots tools: cff.cc on Google Code
In parsettf.c, George Williams wrote that
"TrueType is a really icky format." ...Now that I understand it better it seems better designed, but the docs remain inconsistent. Sometimes badly so.
IMO, the cff spec is just as bad.
Maybe it is better designed. I might eventually look into it to confirm, but it might just be too old to be good.
What old things are good? Parents, math and philosophy :)
Anything else must be up-to-date!
CFF(Compact Font Format) is mainly used for embedded PostScript font in PDF files. And you can also find CFF in OpenType font files which is based on PostScript outlines.
If you got CFF from the embedded font file of a PDF, you can get a PostScript name from the NameIndex of the CFF. You should find the corresponding OpenType File by the PostScript Name.
If you got CFF from a OpenType file, why did you ask this question? :-D
I quote this link: Raster, Vector, TrueType, and OpenType Fonts
... the glyphs for a font are stored in a font-resource file. ...
So, Windows loads glyphs from a file with a format that it understands, not a CFF file, and not a structure from memory. If you want to draw CFF files without using a file conversion tool, I think you will need to load the CFF and draw the glyphs by yourself.
To load the CFF and determine the glyph, you can use the FreeType Project. Here is a link here on SO that explain how to build a Win32 DLL from FreeType source: Compiling FreeType to DLL (as opposed to static library)
To draw the glyphs, you can get some inspiration from the gdipp project, which is a replacement of the Windows text renderer, and contains Win32 C/C++ sample code that display glyphs loaded from FreeType.
It appears that the CFF format was made to be embedded directly into an OpenType file. Microsoft has a good overview of OpenType files: http://www.microsoft.com/typography/otspec/otff.htm
I'm working on an Font Identification tool which runs natively on both Windows XP/7/Vista and Mac OS X and needs to perform high-speed quality rendering of Outline fonts.
As we needed high performance & multi-platform developing environment, we choose a Qt4 / C++ combination and we use freetype2 for font rendering.
By the way, I'm really impressed from the stability, performance & code quality of the freetype2 library and I highly recommend it!
When we switched from Qt4 internal font rendering to freetype2, the product performance increased by about 300% while the probability of an app-crash due to a bad font is lowered from 1:10.000 to 1:200.000.
Our product currently supports OpenType (OTF) and TrueType (TTF) fonts and we are about to add support for Postscript Type 1 (PS1) fonts.
In fact we have already added support for Windows Type-1 fonts but I have a real trouble to find the required information to handle Mac OS Type-1 fonts.
You can see some platform-depended differences of Type-1 fonts here:
http://www.asy.com/fonts.htm
On Windows, each Type-1 font is contained in 2 files: font-name.pfb (the font outlines) and font-name.pfm (the font metrics, kerning, etc)
To open a Type-1 font + metrics with freetype2 you can just do the following:
ftError = FT_New_Face(&ftLibrary, "font-name.pfb", ftFaceIndex, &ftFace);
if (ftError)
(...)
ftError = FT_Attach_File(ftFace, "font-name.pfm");
if (ftError)
(...)
I have the following issues/questions regarding Mac OS X:
1) Is there a corresponding *.pfm (metrics) file? and if the answer is yes, does it always exist on any given Mac-Type-1 font?
EDIT/Answer: There is no *.pfm file in Mac Type-1 fonts. The font-metrics are stored inside a bitmap font stored in the same Font-Suitcase. See the following link about transferring fonts between Windows & Mac, explaining many of the differences between Win-Type-1 and Mac-Type-1 fonts: http://www.macdisk.com/fontsen.php3
2) Is there a corresponding *.pfb (outlines) file?
My info so far is that an outlines file exists and it has no extension (pfb) but a "Mac type" of LWFN. How I can read the "LWFN" type associated with a file while scanning for all such Type-1 files on a given directory?
In general: How to handle Mac data/resource files and File-Types using Qt & C++ ?
3) Are those files (1),(2) exist always in the same directory?
EDIT/Answer: This question is no longer meaningful, after asnwer(1) [=there is no *.pfm file in Mac-Type-1 fonts].
4) If I know the filepaths of (1),(2) for a specific font, is it possible to install the font by just copying the files into User's font library folder (which is true for OTF/TTF fonts) or I have to use some other special installation method?
EDIT/Answer: The Mac-Type-1 fonts comes inside a Font-Suitcase. The correct installation method is to install the whole Suitcase to User's font library.
5) Is it possible to take a Windows-Type-1 font (pfb/pfm) and install/use it on a Mac OS X machine, without any conversion?
EDIT/Answer: The answer is NO. The pfb/pfm need conversion to be installed/used in Mac OS X but you can use them by Adobe applications like Photoshop/Indesign if you copy them to some special fonts folder of these Apps.
I will really appreciate any answers or links pointing to the right direction, because any search I have done so far, just points to another level of complexity without getting me any definite or useful answers.
Thanks
Fivos
PS: I tried to answer most of my questions, and I will also post a link to some pieces of code I have found.
I answered most of my questions by editing my original post. For future readers: I have found some piece of open-source C code which addresses the problem of handling Mac Font Suitcases and extracting OTF/TTF/Type-1 fonts from them.
It's a set of tools written by George Williams (see the description bellow).
The link to open-source project: http://fondu.sourceforge.net/#Fondu
Fondu -- A set of programs to interconvert between mac font formats and pfb, ttf, otf and bdf files on unix.
Dealing with mac fonts is hard on other operating systems because mac fonts are stored in the resource fork, and other operating systems do not support this concept. Fondu will extract the resource fork from either a macbinary file or a binhex file. Ufond will create a resource fork inside a macbinary file.
I am using 2 500K bitmaps in to display images on my WiX dialogs.
They dramatically increase the size of the installation package, and what is worse - it looks there's no way to package them as a part of a .cab file since they're <binary>-es in the WiX terms.
So, I thught, is there any way to use other file formats for bitmaps or WiX is tethered with BMP? Ideally it would be greate if there's a way to use .png format since it comes with a looseless compression option.
The Windows Installer documentation for the Bitmap control states that the image should be a "bitmap" -- presumably a .BMP file -- or a JPEG.
You have to remember, when working with WiX, that it's based on Windows Installer. This means that any limitations in WiX are often caused by limitations in the underlying Windows Installer implementation.
.BMP files can be RLE-compressed. I don't know if they support any other compression algorithms.
The WiX toolset isn't tethered to BMP and JPG. As you've found you could put any of those other image formats into your package. However, the MSI SDK only documents BMP and JPG support.
Yes, if you only need to install on Windows 8 or later. From Bitmap Control:
Windows 8 and Windows Server 2012: The image file can be in any
standard format supported by the Windows Imaging Component (WIC),
including TIFF, JPEG, PNG, GIF, BMP, and HDPhoto. The control does not
support animation.
As was stated in other answers the image format limitation comes from Microsoft's implementation of MSI, and not from WiX. Although .jpeg seems to be supported starting from Windows 7, and PNG starting from Windows 8, be very careful about the format you use. Your trade-off is the look of your installer.
My experience showed that the only reliable way to ensure that your resulting installer displays your images correctly is to use uncompressed BMPs. And that is it! Yes, I know they balloon the size of the final file, but, hey, like everything else with Microsoft they are ages behind and there's no way around it.
So if you don't want to have your installer to display gray squares on Windows XP or Vista instead of your graphics, don't use anything other than raw .bmp format.