Blanks too large in VPE6

[ds-hanau]

Hi,

with VPE-DLL version 6.1.1.7041 there is a problem with the font "FSMillbank Light" regarding blanks.
They are much larger than in Word (both in print preview and on the actual print).

When printing the exact same document with VPE-DLL Version 3.50.0.1 it looks fine however.

VPE 6:


Word:

[IDEAL Software Support]

Please note that VPE v6.x is no longer maintained. You can download the current v7.0 trial version to verify if the problem does exist there, too. v7.0 can be installed on the same machine in parallel without problems.

If the problem should exist in v7.0 also, please provide source code, so we can understand what you are exactly doing, regarding font size and text layout. In general it is no good idea to try to achieve word positioning by inserting blanks. Instead, slice the text into its parts and output each part at desired positions as a new text object.

[ds-hanau]

Hi IdealSoftware Team

I have prepared a sam,ploe application written in C# with the newest vpe version 7.
You can see the effect in this sample.
How can I deal with it?

You can find the sample file here C# application:
Unfortunalety I cannot add files to this thread.
Therefore I have uploaded my sample code to one free file hoster:
http://www.filedropper.com/vpefonttest

But in the end, the main part of the sample code is posted below:

Code: Select all

public static void CreateVpeTest()
        {
            using (var vpeControl = new VpeControl())
            {
                vpeControl.OpenDoc();

                vpeControl.Write(5, 2, 20, 20, "[N B ]Hanauer Anzeiger und noch mehr Text");
                vpeControl.Write(5, 3, 20, 20, "[N B ]Lieferanschrift 1");

                // we have several fonts which have the same strange effect
                vpeControl.FontName = "FSMillbank Light"
                //vpeControl.FontName = "DaxOT";

                vpeControl.Write(5, 5, 20, 20, "[N B ]Hanauer Anzeiger und noch mehr Text");
                vpeControl.Write(5, 6, 20, 20, "[N B ]Lieferanschrift 1");

                vpeControl.ScaleMode = ScaleMode.FullPage;
                vpeControl.PreviewDoc(-1, -1, -1, -1, PreviewState.Maximized);
            }
        }

Thanks for your support

[IDEAL Software Support]

We have this font not available, and it is very expensive.

But it seems there is a problem when you specify bold for a light font.

What happens, if you remove the [N B] flag?

[ds-hanau]

Hi IdealSoftware Team

Same issue when removing the [N B].
I dont know if I can find a font which is free so you can test the issue ...

Here is a comparision between DaxOT and Arial
Is that a point?
http://www.filedropper.com/daxot

[IDEAL Software Support]

Indeed this is an important hint. VPE does only handle True-Type contours, not PostScript.

This is clearly said in the manual.

[ds-hanau]

Thank you for your support

I read this information in your manual thats the reason why I have posted this hint here.
But can you explain me why this worked in your old vpe version? the manual said the same.

In addition this is a new commercial font and not an old one. Im no expert in fonts but is it possible that you can extend your vpe in order to support these font types. I've never heard that a certain new font is not supported

Or is it possible to convert a font just before printing in a font which supports the vpe?

Thank you for your advice

[IDEAL Software Support]

It worked in versions below 4.0 (i.e. before 2007), because we had been using the Windows API to handle fonts. For platform independency - and to gain identical text layout on each supported platform - we created our own font manager. This font manager only handles fonts with True-Type contours.

Creating the font manager required about 6 months of work (including all bug-fixes). Extending it to handle PostScript outlines might require about additional 3 - 6 months. The problem is not to read the font structure, but VPE provides font subsetting for PDF export. Subsetting means that fonts embedded into PDF do only contain the glyphs that are actually used in a document, which makes the embedded fonts as small as possible. But this means to assemble on-the-fly a whole new font file, with all tables and structures conforming to the specifications. This is not a simple task, as the specifiation is huge (see http://www.microsoft.com/typography/otspec/otff.htm - each table listed there is a link to a separate web page). It would also require to extend our PDF generator to write new PDF structures for embedded PostScript outline fonts (which are called CFF). Therefore we have currently no plans to support CFF.

Regarding your question about font conversion: quickly googling for "cff to true type conversion" yields several results. We didn't dig into it, but it looks promising. If you find a good conversion tool, please let us know here, so other users can benefit from this thread.