Hi Steve,

I supposed you altered all FreeMono fonts because I spotted that the acute and grave accents changed in all FreeMono fonts and some glyphs are improved now in FreeMono Bold and Bold Italic. If you changed only FreeMono Regular then someone else had to change these other fonts.

“I may send you one further trial, just to be sure.”

Let me know when it’ll be ready.

*

“The next steps will be (a) to look at the driver files to see if there is anything more to learn from them (b) consider whom to write regarding the bug (c) consider changing the flag in the rest of FreeFont.”

If you mean the printer driver I use you can download the PPD file for Brother HL-5340D from here: http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/download_prn.html.

However in the comment #10 you wrote:

“I looked through the Brother ppd file. I see nothing in there that should have caused these issues.”

So you saw that driver already and I you didn’t find something suspicious.

*

I recreated references in both GNU FreeFont 20100919 and 20120503. You changed some flag in FreeMono. It’s interesting that these two different methods of altering these fonts improved printouts from my printer.

“It is a pity to lose that useful feature due to a bug in third-party software.”

So don’t change that flag at all. Assuming it stores some useful information it isn’t good idea to reset it.

I’m not TTF guru so I can only suppose that changing that flag improves my printouts as a side effect. I still think that the problem is in incosistencies in those fonts. I described those inconsistencies in a detailed way in my comment #14 from February 6, 2011. There was a mess with the accents in GNU FreeFont. You replied nothing to that comment and our discussion died. I doubt you read that comment and analized the fonts.

The FreeFont changed a lot since 2011. I’ll inspect the current version when we’ll finish to test and modify it. Or maybe we finished that already? Both of us think that it’s better to leave that flag unchanged. I discovered that recreating the references repairs some flaws. I used that method on the entire fonts. Of course one can unlink references and replace them for the individual glyphs. It’s time consuming but safe process. You didn’t take that into consideration criticizing my method. I’m aware that automatic reference recreation is unacceptable for the designers of these fonts. It works for me with the glyphs I use though it spoils the other glyphs ‒ I reported that as well. A designer can repair glyph by glyph or maybe examine the range of the problem in the entire font and write a script repairing the selected glyphs.

Let me know what you intend to do. If we reached the dead end I can live with my brute force method.

*

I stated that FreeMono is based on Courier New because Courier New is older than FreeMono. Of course FreeMono offers much more characters than Courier New so it isn’t a copy but an expanded version of that font. Both of them are based on the typeface redrawed by Adrian Frutiger for IBM electric typewriter. That typeface in turn was based on the typeface designed by Howard Kettler for a mechanical typewriter.

I got my old mechanical typewriter from the basement and I typed the complete character set. Both Courier New and FreeMono imitate the shapes of the font used in the typewritter. Someone could call that the homage payed to the past.

In my mechanical typewritter as well as in Courier New and Free Mono:

‒ the dot over i is smallest,

‒ the dot below ! is slightly bigger,

‒ and the dots in : and . are much bigger (in the case of the typewritter the single . is the biggest one).

It was machanically justified. The character that has biggest area such as i has the smallest dot. The character that has the smallest area such as : or . has the biggest dots. Typebars are from metal. The roller is from rubber. Let’s assume that one types on the mechanical typewritter with the same force all the time. Despite of that when she type . that force is concentrated but when she types i that force is distributed. (It’s enough to see the other side of the paper sheet: the characters of a small area almost perforate the paper.) So to minimize that effect these dots have bigger size in the mechanical typewriters. That’s the reason of such a design.

In an electric typewriter manufacturer could set up the force individually for each character. So the dots of the different size weren’t justified in that case. Frutiger decided to imitate that design taking into consideration rather emotional reasons than related to the physics. It was the homage payed to the past. From my point of view it’s illogical.

In the case of the computers and the printers such a design of the font isn’t justified at all. That’s my point.

Copying good traditional design doesn’t produce good modern design in most cases.

My attitude from comment #28 is very strict and bases on consistency. The world isn’t strict nor consistent so the fonts don’t have to be consistent too. I understand that. But they could be.

*

Misunderstanding. I just juxtaposed Liberation Mono that is internally consistent with Courier New and FreeMono that aren’t internally consistent. The reason of that inconsistency is historical as I described that above. So I didn’t compare these fonts nor suggest to make FreeMono alike Liberation Mono. I just suggested that it’d be good idea to made FreeMono more internally consistent in the design. (Don’t confuse that kind of inconsistency with the inconsistency in the construction of the glyphs ‒ the first affects the look of the font and the other affects how the font behaves in different situations.)

*

“Did it occur to you that part of your impression might be, that the letters in Liberation Mono are just bigger?”

It is indeed.

I have the other problem: sansserif fonts such as FreeSans or Arial are higher than serif fonts such as FreeSerif or Times New Roman when used in the same pointsize. So I try to avoid to mix them in the same praragraph and when I should do that I slightly decrease the pointsize of the sansserif font.

*

“With regard to which marks should be round and which square, I reject your pronouncement as nonsense.”

It was remark about the consistency. If i in FreeMono has rectangular dot then the other dots should be rectangular as well as of the same size as the dot above i. Howard Kettler designed his typeface in mid ’50 of the 20th century for the mechanical typewritter. We live in the 21st century and we use the computers and the printers so we don’t have to copy those old projects ‒ we should modify and adapt them.

*

“It looks like you just got up on the wrong side of the bed. ”

No comments.

Hi Steve,

I tested GNU FreeFont 20121211. In some cases it’s better than the official version 20120503. In order to show you the exact result of the printing I added the FreeMono section with spacing between characters because in the first FreeMono section some glyphs on the printout have doubled accents: their own ones overwritten with the accents coming from the consecutive glyphs. 

I attach FreeFont-20121211-diacritics.gif illustrating those changes:

‒ ËÏÜëü in FreeSerif and FreeSans are the same as before;

‒ ĆŃÓŚŹ ÉÀÈÙ in FreeMono Regular, ĆÓŚŹ É in FreeMono Bold, and ĆŃÓŚŹ É in FreeMono BoldItalic are better than before (you did a good job here);

‒ Ńćńóśź ÀÈÙéàèù in FreeMono Bold and ćńóśź ÀÈÙéàèù in FreeMono BoldItalic are similar as before (you apparently didn’t change these glyphs too much).

● In GNU FreeFont 20121211 some acute and grave accents used in some glyphs have the better position now than in GNU FreeFont 20120503 (see: FreeFont-20121211-diacritics.gif).

Unfortunately investigating my printouts I spotted the other problem concerning some punctuation marks
as well as a completely new problem concerning FreeMono.

I printed the following string:

=@#$%^&*-=+[{]}\|<>/()_iïŻżÓ!?;:,.’"“„”«»

and I attach FreeFont-20121211-punctuation.gif illustrating those problems:

‒ The » in FreeSerif Regular is spoiled;

‒ There’s something wrong with «» in FreeSans Regular;

‒ There’s something wrong with “„” in FreeSans Bold.

● In GNU FreeFont 20121211 the following «» “„” quotes are spoiled in FreeSans Regular and Bold (see: FreeFont-20121211-punctuation.gif).

*

The next problem deserves in my opinion the separate bug report. I mention that here provisionally. Let me know whether I should report that separately.

In that case I discuss the design of the different glyphs. They look the same on the screen and on the printouts. Unfortunately they look bad.

Let’s compare the string =@#$%^&*-=+[{]}\|<>/()_iïŻżÓ!?;:,.’"“„”«» in FreeMono, Courier New, and Liberation font families as I showed that in FreeMono-CourierNew-LiberationMono.gif.

Someone who designed these glyphs in FreeMono followed Courier New font from Microsoft FontPack. She had her own invention only in the case of ’“„”. The acute accents over Ó and the other glyphs in GNU FreeFont 20120503 were the same as in Courier New. After your last changes these accents changed the shape. Just compare abiword-2.8.6.gif and FreeFont-20121211-punctuation.gif.

My point is: Courier New isn’t designed well and copying it isn’t good idea. For the comparison Liberation Mono font family is designed much better.

What’s wrong with FreeMono and Courier New:

‒ Taking into consideration that the dot over i is rectangular in the shape the other dots used as the accents (in dot accent or diaeresis accent) or used in punctuation marks such as colon, semicolon, and dot as well as used in exclamation and quotation marks should be rectangular too. Just compare FreeMono and Courier New that are designed bad to the Liberation Mono that is designed well.

‒ FreeMono font uses the lines of the constant thickness for =@#$%^&*-=+[{]}\|<>/ and that works well. To be consequent the thickness of the lines in ()!«» should be constant as well. The same with the thickness of the lines in acute, grave, and the other accents as well as in ;,’"“„”.

So to be consistent:

1) All dots should be square or have parallel sides and sharp corners.

2) All lines should be of the equal thickness.

*) It’s disputable whether the lines should have sharp or rounded endings.

The changeable thickness in Liberation Mono is justified because all oval glyphs such as @$%&{}()? use the lines of the changing thickness and the same is with *[] and ;:,.’"“„” glyphs. Of course the letters use that too. So Liberation Mono is consistent. 

Meanwhile in FreeMono which is almost a 1:1 copy of Courier New we have mixed oval and rectangular dots and mixed glyphs using the constant or the changing thickness. It’s horrible and should be repaired.

● FreeMono is based on Courier New and is inconsistent in the design ‒ that should be repaired (see: FreeMono-CourierNew-LiberationMono.gif).



(file #27087, file #27088, file #27089)

Hi Cezary,

It's late here, and I can't read all this now...

The most important thing to me, was for you to try the snapshot I made for you.

Did you misunderstand me?

It's already built, on the google drive link I sent you.
I sent the link to the address associated with your Savanna account. 
You should be able to download and install it directly.

If this doesn't work for you, we can find another way.

Hi Cezary,

1) I have a snapshot of the latest build.  You should get a link to it in a separate e-mail.

FreeMono is changed in ways that might affect your tests.
Please re-check with the snapshot, and tell me what you see.

2) OpenType: It is significant that the problem occurs only with TrueType font versions.  The glyph reference flags I mentioned are supposed to be meaningful only for TrueType.

3) It would be nice to see visually what you are seeing.

Could you send an image of one of your print-outs?
(Any sharp image -- e.g. from a cell phone -- will do.)

4) Please confirm that the problem occurs only with Open/Libre Office.  (E.g. try the same test from FireFox.)

Please report the version number of the application where the problem occurs.

I ask this, not to somehow avoid fixing the problem, or to trivialize it, but in order to properly report the problem.
See below.

5) It would be nice to try at least one other non-Brother PostScript laser printer, using the exact same computer and software.

As you said, nobody else has reported this, but then again, we're not 100% sure what in your system causes the problem.
And mine is not a PostScript printer.

6) My view is that the goal of this process, is to find the cause of the problem, so that it may be reported to the responsible parties and fixed.

Something in FreeFont evidently triggers the problem, but I do not regard it as the cause.  These are two different things.

The font is a data file, whose settings, I think, are valid.
Some software is misinterpreting those settings.  The misinterpretation is the cause of the problem.

It may be the particular settings are rare among fonts, or even unnecessary, but that does not change the responsibility of the software to interpret them properly.

Even if we identify the trigger in FreeFont, and even if I decide to remove it, we really should alert the people whose code has the problem.  This is good team playing.

I'm not so sure anymore.  I found a few glyphs you tested, which have the flag set, yet you say print OK.  Maybe some combination of things, or maybe something completely different.

But without a tester who has one of these printers, we're stuck.

Cezary,

There may be some misunderstandings.

1) You didn't respond to my suggestion about doing tests to narrow down what triggers the bug, except to say perhaps somebody (else) would be willing to perform the tests.

This might only take a few iterations of installing a test font, and printing your test with it -- as I mentioned, I may have found a "smoking gun".

However, I'm afraid that unless you will help with the testing, there will be no "going forward".  Since you are the only person I know with a printer that shows the problem, this can only be done by you.

I am interested in helping you with this problem.  I have no doubt that you see a problem.  I doubt that it is a FreeFont bug, per se -- but it seems something in FreeFont triggers it.

I had hoped, since you have already expended this much time on this issue, that you would be interested to know what causes the problem.  I certainly am.

2) You said you're using the TTF files on Linux.

You know, the OTF files are preferred on Linux -- the TTF ones perform better in Windows. (This is stated in a couple of places.)

What happens with the OTF version of the font?

4) I'm still not sure I understand your exact set-up -- the posts are long and complicated.

Particularly, I had not understood that the problem only occurs when printing Open/Libre office. Reading back through your posts, I have tried to sort it out. Tell me if this summary is correct:

• Issue occurs on (undisclosed versions of) Windows and Linux.
• Happens only in Libre- and Open-office (vers. not reported)
• If you first save as a PDF file, the file prints properly.
• If you print directly from the app, the problem appears.
• The affected printer is a Brother HL-5340D

5) I printed your sample from L/O 3.5.4.2 on my Canon printer.  The results were identical to those produced by FireFox, same as the attached photo--all accents in place.

This and (4) changes my guess as to what's going on.  Since there are several layers of software here, and it's specific to L/O, I no longer consider it to be a "driver-only" bug.

6) Printing from PDF might be quite different from printing from L/O. 

In PDF, all that remains of the font is graphical elements (glyph outlines taken from the font) and positioning information.  I don't know the exact procedure used by L/O, but it might render the letters in a very different way.

As the Brother HL-5340D emulates PostScript on-board, the most obvious thing to do with a PDF is to just transfer it to the printer without change.

L/O has its own font rendering libraries, separate from the OS.
Evidently that software, together with the driver for this specific printer, produce a glitch that is triggered for certain glyphs in FreeFont.

7) My current guess as to what in the font triggers the problem: one or both of the TrueType 'glyf' table component flags
   ROUND_XY_TO_GRID
   WE_HAVE_A_SCALE
(I noticed that FontForge re-sets these after a "remove references"+"replace reference")
I understand that these flags apply only to TrueType fonts.
https://developer.apple.com/fonts/TTRefMan/RM06/Chap6glyf.html

Hi Cezary,

I've tried your examples on several printers, all with perfect output.  See attached photo: your text, using the attached HTML file in FireFox, printed with a Canon iP100.

My first diagnosis stands: this is a printer driver bug.  I'm unlikely to make any changes to our product, to sweep a proprietary product's bugs under the rug.  Moreover, I don't even have access to the buggy device--which would make any changes impossible to check later.

So what can be done?

Maybe we can narrow down what triggers the driver bug.

I tried the cycle of removing and replacing references.  This is not a reversible process--information is lost.  I noticed that, in particular, a couple of flags are lost for references.  One guess is, your printer driver trips on one of these flags.

If you're willing, I could send you some test builds.  Hopefully in a few cycles, we can find what ails your driver.

(file #27061,

Hi Steve,

I finally managed to register my account in Savannah so if you’d like to continue the discussion out of the submission page feel free to write an e-mail to me.

Bye,
cmk

Steve,

I compared FreeFont I generated from 20100919 version with FontForge using two options: Unlink Reference and Replace with Reference to FreeFont available in CVS February 4, 2011 at 4:00 PM.

As for general comparison all characters in my fonts use always Round To Grid option while characters in your fonts use frequently Use My Metrics option indicated by small padlock in the character’s view. Taking into consideration the original FreeFont in 20100919 version uses Use My Metrics option I suppose that unlinking references and replacing them with the new ones switched automatically all characters from Use My Metrics option to Round To Grid option.

FreeSerif regular type as well as Bold, Italic and BoldItalic types in my and your versions work similarly though not identical. There’s the problem with a dieresis accent (U+0308). It’s referenced as “dieresis” except for your Italic type in which it’s referenced as “dotaccent dotaccent” though when used with letters it’s always referenced as “dieresis”. In the case of the uppercase letters dieresis is significantly shifted down and left on the printouts. In the case of the lowercase letters it’s slightly shifted to the left on the printouts. There’s also the problem with ligatures DŽ, Dž and dž. The letters Ž or ž cover the letters D or d when printed. The above problems concern both my and your fonts. The first difference between your and my fonts concerns the letters with a double grave accent (U+02F5). In your fonts that accent is referenced as “grave grave” or “gravemodifier gravemodifier” so there’s inconsistency. When used with letters it’s referenced as “dblgravecmb” or “gravedblnosp” so there’s the consecutive inconsistency. With your types the printer prints the characters using that accent bad. In my font that accent is referenced as “grave grave” as is and when used with letters and the printer prints it well. The second difference concerns a breve inverted accent (U+0311). In your fonts it’s sometimes referenced as “breve” and sometimes unreferenced – in my fonts it’s always unreferenced. When used with letters in both your and my fonts it’s referenced as “breveinvertedcmb”. It’s printed bad with your FreeSerif regular and FreeSerif Bold types in which that accent is referenced as “breve”. I think using the same reference “breve” for breve accent and inverted breve accent isn’t good idea. With my types it’s printed well.

FreeSans regular type as well as Bold, Oblique and BoldOblique types in my and your versions have the same problems with a dieresis accents as well as DŽ, Dž and dž ligatures. As for double grave accents in my fonts it’s referenced as “grave grave” or “gravemodifier gravemodifier” in the case of Oblique so there’s some inconsistency. In your fonts that accent is always referenced as “gravemodifier gravemodifier”. Used with letters it’s almost always referenced as “gravedblnosp”. Just in my BoldOblique it’s referenced as “grave grave”. With your fonts that accent behaves well when printing while with my Oblique and BoldOblique types it behaves bad. As for a breve inverted accent in my fonts it’s unreferenced and in your forts it’s always wrongly referenced as “breve”. When used with letters in most cases it uses the reference “breveinvertedcmb”. There are two inconsistencies: in my BoldOblique it uses the reference “uni0311” and in your Bold it uses the reference “breve”. Regardless of all those differences when printed with your fonts that accent looks bad while when printed with my fonts it looks well. The last difference concerns character Ǻ in your fonts in which the letter A in is too low on printouts.

FreeMono regular type as well as Bold, Oblique and BoldOblique types give different results in the cases of your and my fonts. With your fonts a dieresis accent is in place when printed. With my fonts it’s in place only in the case of BoldOblique type. The problem with dieresis accent affects uppercase characters. On the other hand my fonts have good grave and acute accents when printed. These accents are always referenced in my fonts as “grave” and “acute”. In your fonts the same accents are referenced as “gravecomb” and “acutecomb”. Your fonts give good printouts in the case of FreeMono lowercase letters and BoldOblique type. Your accents are referenced as “uni02CB” and “acutemodifier” or “gravecomb” and “acutecomb” or “grave” and “acute” so there’s a lot of inconsistencies here. My accents are always referenced as “grave” or “acute”. All accents referenced as “grave” and “acute” are printed well. In the case of the mentioned FreeMono lowercase characters they have “uni02CB” and “acutemodifier” references and give good printouts too. All your fonts except for Oblique have more or less of problems with a macron accent (U+02C9). That accent when used with letters is referenced in your fonts as “uni02C9” or “macroncmb” when printed bad and “macron” when printed well. In all my fonts it’s referenced as “macron” and printed well. Double grave accent is referenced in my fonts as “grave grave” and in your fonts as “gravecomb gravecomb”. That accent is printed bad with your fonts with the exception of FreeMono regular type and it’s printed good with all my fonts. In my fonts it’s referenced as “grave grave” when printed good. In both your and my fonts it’s referenced as “gravedblnosp” when printed good. In your fonts it’s referenced as “dblgravecmb” when printed bad. So both your and my fonts have some inconsistencies though my fonts are always printed well. As for a breve inverted accent in my fonts it’s unreferenced while in your fonts it’s wrongly referenced as “breve”. In both your and my fonts that accent when used with letters it’s referenced as “uni0311” or “breveinvnosp” or “breveinvertedcmb”. In your fonts it gives bad results in all cases except for Bold lowercase characters. In my fonts that accent is printed well. As for a caron accent (U+02C7) it’s printed bad with your BoldOblique type uppercase characters and printed well with all my types. Both your and my types use reference “caron” for it when used with letters. That accent itself is unreferenced in both my and your fonts except for your BoldOblique which uses wrong reference “circumflex”. Moreover FreeMono prints instead of the string ȡȢȣȵȶȷȸȹȺȻȼȽȾȿ completely different set of characters.

After the comparison of my and your versions of FreeFont typefaces I decided to review Linux Liberation Serif, Sans and Mono fonts as well as Microsoft Times New Roman, Arial and Courier New fonts.

Liberation Serif, Sans and Mono – not all characters from the ranges I tested are implemented in those fonts. In such cases the system uses characters borrowed from some other fonts. It seems the original characters from these fonts are printed well. Some problems appear with substituted characters. These problems concern invalid positions of accents on printouts as well as invalid weight and slant of some characters.

Times New Roman, Arial and Courier New – similar problems as with Liberation family fonts.

Liberation and Microsoft fonts behave well in two basic ranges:

ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß
àáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
ĀāĂ㥹ĆćĈĉĊċČčĎďĐđĒēĔĕĖėĘęĚě
ĜĝĞğĠġĢģĤĥĦħĨĩĪīĬĭĮįİıIJijĴĵĶķĸĹĺĻļĽľĿŀŁł
ŃńŅņŇňʼnŊŋŌōŎŏŐőŒœŔŕŖŗŘřŚśŜŝŞşŠš
ŢţŤťŦŧŨũŪūŬŭŮůŰűŲųŴŵŶŷŸŹźŻżŽžſ

The problems with these fonts concern the range:

ǀǁǂǃDŽDždžLJLjljNJNjnjǍǎǏǐǑǒǓǔǕǖǗǘǙǚǛǜǝǞǟ
ǠǡǢǣǤǥǦǧǨǩǪǫǬǭǮǯǰDZDzdzǴǵǶǷǸǹǺǻǼǽǾǿ
ȀȁȂȃȄȅȆȇȈȉȊȋȌȍȎȏȐȑȒȓȔȕȖȗȘșȚțȜȝȞȟ
ȠȡȢȣȤȥȦȧȨȩȪȫȬȭȮȯȰȱȲȳȴȵȶȷȸȹȺȻȼȽȾȿ

The special problem appears in the range:

ȠȡȢȣȤȥȦȧȨȩȪȫȬȭȮȯȰȱȲȳȴȵȶȷȸȹȺȻȼȽȾȿ

Instead of the above characters Liberation Mono and Courier New fonts give on printouts completely different characters.

Despite of all mentioned problems Liberation and Microsoft fonts behave better when printed than any FreeFont version I tested.

I played a little with Round To Grid and Use My Metrics options but the results achieved on the printouts were always the same. As far I didn’t try to correct inconsistent references manually. I suppose it could improve printing results. I’ll try that soon. Now I’m slightly tired of comparing all those fonts.



cmk

Hi Steve,

I overlooked your former post so I reply to you in a reverse order.

First you wrote: “This problem you reported is not the fault of FreeFont at all”. Then you wrote: “The references in FreeFont did not »cause the problem«”. Finally you wrote: “The changes I have made were only to make the references more consistent among the faces”. As I understand that the last statement denies first two statements. Improving consistency of these typefaces improves printing results. The inconsistencies you mentioned I call the typefaces’ side of the problem. The driver or firmware bug I call the printer’s side of the problem.

When I stated I don’t know what some Unicode ranges are I declared in fact I don’t know how work dependencies among them. So I’m afraid that changing some references here can cause some errors there. I don’t know about these relationships because I’m newbie in Unicode and TTF font domains.

As for the technical details concerning the typefaces and the printer I intend to follow them next week. I’ll report the results here.

Thank you for the wishes. It was happy birthday indeed. See you the next week.

Bye,
cmk

Hi again,

I looked through the Brother ppd file.
I see nothing in there that should have caused these issues.

If that's all there is to the driver, I guess the problem lies in the printer firmware (not technically speaking with the "driver".)

Is it possible to use a non-Brother driver for your printer?
(Most printers talk some standard language: if you can determine that, you should be able to find a non-Brother driver that speaks that language, and use that...)
This would serve to further localize the problem.

Cheers!

Hi Steve,

In Linux I use Brother drivers found here: http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/download_prn.html. One is in binary form and one is PPD file. Both give the same results.

You’re right. I’ll try to report that bug to the Brother guys.

It seems to me that a part of the problem is in FreeFont typefaces and a part in printer drivers or even printer firmware. I inspected a few characters from FreeSerif font you modified and all of them have now references to grave and acute accents. The printer prints now all of them well.

I’m aware the problem I described isn’t restricted to Latin-1, Latin Extended-A and Latin Extended-B. I just tried to determine the scale of the problem.

As yet I don’t understand what Spacing Modifier Letters and Combining Diacritics ranges are. I installed FontForge for the first time four days ago and I tried just a few basic options. So I haven’t  any knowledge about TTF font construction.

It’s the great idea to use references in fonts. I’m not against references. I’m against invalid references. When a few glyphs of the same shape are referenced as different accents it isn’t good. On the other hand some characters from FreeFont 20100919 which cause printing problems have unreferenced glyphs instead of referenced accents. After the restoration of the references they stopped to cause the problems.

Maybe that situation is the result of the work of different people which constructed or modified different characters using different methods. It seems the lacking of the supervisor caused some inconsistencies in these typefaces. Taking into consideration the number of the ranges in the typeface probably it’d be impossible to find someone who could supervise such project.

I’ll try your FreeSerif typefaces next week. Today is my birthday so I don’t work but celebrate. During a few next days I’ll finish some urgent project.

Bye,
cmk

Hello Steve,

I compared FreeSerif typeface in three versions: ready to download 20100919 version, the version I customized for my own purposes and the version you customized and put into CVS. I tested them in Linux and in Windows. In Windows I tried three drivers: Brother HL-5340D series (referenced in User’s Guide as the most suitable printer driver for that product), Brother PCL5e Driver (provided with the printer on CD-ROM) and Brother HL-5340D BR-Script3 (described in User’s Guide as PostScript 3 language emulation for Windows).

To make my tests more extensive I took a few snippets of Latin-1, Latin Extended-A and Latin Extended-B ranges consisting mostly of characters with accents:

ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß
àáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
ĀāĂ㥹ĆćĈĉĊċČčĎďĐđĒēĔĕĖėĘęĚě
ĜĝĞğĠġĢģĤĥĦħĨĩĪīĬĭĮįİıIJijĴĵĶķĸĹĺĻļĽľĿŀŁł
ŃńŅņŇňʼnŊŋŌōŎŏŐőŒœŔŕŖŗŘřŚśŜŝŞşŠš
ŢţŤťŦŧŨũŪūŬŭŮůŰűŲųŴŵŶŷŸŹźŻżŽžſ
ǀǁǂǃDŽDždžLJLjljNJNjnjǍǎǏǐǑǒǓǔǕǖǗǘǙǚǛǜǝǞǟ
ǠǡǢǣǤǥǦǧǨǩǪǫǬǭǮǯǰDZDzdzǴǵǶǷǸǹǺǻǼǽǾǿ
ȀȁȂȃȄȅȆȇȈȉȊȋȌȍȎȏȐȑȒȓȔȕȖȗȘșȚțȜȝȞȟ
ȠȡȢȣȤȥȦȧȨȩȪȫȬȭȮȯȰȱȲȳȴȵȶȷȸȹȺȻȼȽȾȿ

I did the tests and I’m ready to compare the results. I use the naming convention: character is a combination of letter and accent.

● Windows Brother HL-5340D series

That driver prints all three FreeSerif typeface versions – 20100919, mine and yours – perfectly. So that driver is good to gain the printout of reference.

● Windows Brother PCL5e Driver

That driver prints all three mentioned FreeSerif typeface versions perfectly too.

● Windows Brother HL-5340D BR-Script3

That driver used with FreeSerif version 20100919 gives bad results, used with your version of that typeface gives better results and used with my version of that typeface gives the best results, though “the best” doesn’t mean in that case “perfect”.

– 20100919 version: ÀÁÄÈÉËÌÍÏÒÓÖÙÚÜÝ àäèéëíòóöùúüýÿ ĀāĆć – misplaced accents; Ĉ – little blot; ďĒē – misplaced accents; ģ – no accent; ĪĹ弾 ŃńʼnŌō – misplaced accents; Őő – bad accents; ŔŚ ťŪū – misplaced accents; Űű – bad accents; ŸŹź – misplaced accents; DŽDždž – characters Ž cover characters D; ǕǖǗǘǚǛǜǞǟ ǠǡǢǣǬǭǴǵǸǹǻǼǽǾǿ – misplaced accents; ȀȁȂȃȄȅȆȇȈȉȊȋȌȍȎȏȐȑȒȓȔȕȖȗ – bad accents or misplaced accents; ȪȫȬȭȰȱȲȳ – misplaced accents.

– your version from CVS: ÄËÏÖÜ äëöüÿ – misplaced accents; Ĉ – little blot; ģĽľ ʼnŐő ťŰűŸ – misplaced accents; DŽDždž – characters Ž cover characters D; ǕǖǗǘǙǚǛǜǞǟ Ǭǭ ȀȁȂȃȄȅȆȇȈȉȊȋȌȍȎȏȐȑȒȓȔȕȖȗ Ȫȫ – misplaced accents;

– my version – ÄËÏÖÜ äëöüÿ Ÿ – misplaced accents; DŽDždž – characters Ž cover characters D; ǕǖǘǚǜǞǟ Ȫȫ – misplaced accents.

In the above context “misplaced accents” means sometimes serious shift and sometimes very tiny shift.

● Linux

This driver produces the results exactly the same as described above Windows Brother HL-5340D BR-Script3.

*

I wonder why your font produces different results than mine. I used FreeSerif.ttf from freefont-ttf-20100919.tar.gz package. I opened that font with FontForge 20100501 for Linux, selected all characters, used Unlink Reference option and then Replace with Reference option, and at the end I saved that font as SFD file and generated TTF font. Your SFD file I changed with FontForge to TTF font.

I suppose you did something similar. I can imagine two explanations of that difference. Either CVS version of FreeSerif font that you modified was different and in some sense worse than 20100919 version or I converted your SFD file into TTF font in a wrong way.

Cheers,
cezary m. kruk

Hi cmk,

I just submitted changes to the FreeSerif in CVS, along these lines.  If you can look at it, it wuld be nice to know to what degree I've improved things.

Hi, Steve!

In fact I tried to register an account on savannah.gnu.org for two times. The day before yesterday I registered cmk user using an e-mail address on www.bigfoot.com. Unfortunately I didn’t get an e-mail allowing me to finalize the registration process. My e-mail address on www.bigfoot.com isn’t a real address but an alias to the address on www.wp.pl. As I guess your system recognizes that alias as invalid address or recognizes www.bigfoot.com as spammers’ domain. In fact since 1997 when I registered that e-mail alias www.bigfoot.com became domain used by a lot of spammers. But it doesn’t mean each user of that domain is a spammer. So yesterday I tried to register an account for cmk user using real e-mail address on www.wp.pl. Unfortunately your system recognizes now cmk user name as already existing.

In result I can’t use cmk user account registered two days ago because the process of the registration wasn’t finished and I can’t register a new account for cmk user because that login is registered as existing one. It resembles the situation described in famous satirical novel by Joseph Heller. If you or someone else can send to me e-mail finishing the registration or could remove completely cmk user from your system I’ll finish my registration or I’ll register my account anew.

As for the Brother HL-5340D printer I did some researches and I suppose it tries to load separately letters and accents and then it builds complete characters. When it encounters an invalid referenced accent it uses an invalid glyph or uses the right glyph but places it in the wrong place. Windows standard driver copes with that well. Windows BR-Scrtipt3 driver as well as Linux driver build characters in an invalid way. I inspected FreeFont typefaces and I discovered the problem appears when instead of acute or grave accents the particular character uses accents referenced as acutemodifier, acutecomb, gravemodifier, gravecomb or uni02CB. The case of dieresis accent is more complicated. I didn’t solved that problem so far.

I’m sure the same problems appear in the case of the other Brother printers than HL-5340D laser printer and maybe in the case of the printers of the other manufacturers. According to my researches Windows BR-Script3 driver is invalid in fact. As for Linux driver it offers access to the very basic set of the settings of the printer. But fortunately I managed to reduce these problems to minimum simply unlinking references to all characters in the particular FreeFont typefaces and then replacing them with the new references. That operation restores references to the genuine acute and grave accents.

Linux drivers for Brother printers are here: http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/download_prn.html. Among them are the drivers for my HL-5340D laser printer (LPR driver, cupswrapper driver and PPD file). Windows drivers are accessible from here: http://welcome.solutions.brother.com/bsc/public/us/us/en/dlf/download_top.html?reg=us&c=us&lang=en&prod=hl5340d_all. As I stated above standard Windows driver works well. Windows PostScript BR-Script3 driver works bad. So it’s better to test FreeFont using Linux drivers which work bad in all cases. If you need to see these problems yourself you have to find some user of Brother laser printer or maybe better a user of Brother printer from HL series.

As for PDF files and printing to the file both OpenOffice.org and LibreOffice generate good PDF files using FreeFont typefaces and print good PostScript files with those typefaces. The problems appear only during printing with the printer.

Cheers,
cmk

The problem described below affects at least FreeFont 20090104 and 20100919. It concerns accented characters – at least some characters using acute, grave and dieresis accents. It appears during printing those characters with at least Brother HL-5340D laser printer. The problem appears at least in Linux and in Windows used with BR-Script3 printer driver. Windows used with standard printer driver prints all characters in a good way. OpenOffice.org or LibreOffice display those characters well. Brother printer prints them in a bad way.

I inspected FreeFont typefaces with FontForge and I stated the problem appears when the character instead of acute accent uses acutemodifier or acutecomb accents or instead of grave accent uses gravemodifier, gravecomb or uni02CB accents. Affected characters are for example: Ó, ó, Ć, ć, Ń, ń, Ś, ś, Ź and ź Polish diacritics as well as: À, à, Á, á, È, è, É, é and Ï French diacritics. Polish diacritics are bad in: FreeSerif, FreeSans, FreeSansOblique, FreeSansBoldOblique, FreeMono, FreeMonoBold and FreeMonoBoldOblique typefaces. French diacritics are bad in all typefaces except for FreeSerifBold and FreeMonoOblique typefaces.

I tested a few methods of debugging these invalid typefaces. The faster method I found is to unlink references to all characters in the typeface and then replace them with new references. Unfortunately that method doesn’t repair Ï diacritics in most FreeSerif and FreeSans typefaces. Moreover using that method spoils at least Ï diacritics in most FreeMono typefaces. So after recreating the references the further research will be necessary.