bugFree UCS Outline Fonts - Bugs: bug #32220, Some printers print ugly some...

 
 

bug #32220: Some printers print ugly some accented characters

Submitted by:  None
Submitted on:  Sun 23 Jan 2011 11:56:52 PM UTC  
 
Category: individual character(s)Severity: 3 - Normal
Item Group: printingStatus: Proceeding
Privacy: PublicAssigned to: Steve White <Stevan_White>
Open/Closed: OpenRelease: 2010-09-19

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 13 Dec 2012 10:56:58 PM UTC, comment #30:

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.

cezary m. kruk <cmk>
Thu 13 Dec 2012 11:19:57 AM UTC, comment #29:

Hi Cezary,

Regarding your test of the 20121211 snapshot:

I only (deliberately) changed the flag in FreeMono (regular): The accents of this face are placed correctly in the snapshot.

This is great. We may have found the trigger.

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

The double-spaced test also shows something new about the driver bug. The horizontal placement is also way off, evidently.

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.

The option (c) is possible. In FreeMono, the flag is essentially meaningless. In the proportional faces, I actually set it deliberately at times. (Mostly it was set by something/someone else... not clear.) It does something useful: it says the width of a compound glyph should be the same as one of its components.

It is a pity to lose that useful feature due to a bug in third-party software. Furthermore, I may have to write a script to do this properly, as there are thousands of cases.

Regarding the punctuation test:

I print the same string on my printer, and see none of these issues. That is, the test shows further examples of driver bugs.

In these marks, I don't see the flag set, which I now think triggers the accent placement bug. So maybe more tests are in order.

Regarding the rest of your report: it is very unfortunate.

Yes, it does not belong here, and I am really not happy that you wrote some of this in a public place.

I am particularly dismayed by the false accusations.

FreeMono is not based on Courier New (or vice-versa). The two look similar because they share a common heritage.

At no point was information from Courier New copied into FreeMono. At no point did we alter FreeMono to make it more like Courier New.

This is all easy to check. The heritage of GNU FreeFont is documented on the FreeFont site, and in the documents that come with the FreeFont package.

The rest of your report a confusion of correctness with taste.

The Liberation fonts are a different style. (It is a good thing that fonts have different styles!). First off, Liberation Mono is sans-serif, where the other two are serifed. It does not derive from the Courier tradition at all. Stylistically, you are comparing apples with bananas, and saying apples are good and bananas are bad. (Couldn't you have spoken in terms of "preference"?)

It is very suspicious to me that in your image comparing FreeFont with Courier New and Liberation mono, the letters from Liberation Mono are much taller and heavier than those of the other fonts.
Did it occur to you that part of your impression might be, that the letters in Liberation Mono are just bigger?

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

It is difficult for me to sort out whethre there is anything to be done about any of this. It looks like you just got up on the wrong side of the bed.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Thu 13 Dec 2012 12:56:10 AM UTC, comment #28:

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)

cezary m. kruk <cmk>
Wed 12 Dec 2012 12:37:12 AM UTC, comment #27:

I don’t misunderstand you. The only e-mail message I got from you came two days ago and starts with the following reference:

Follow-up Comment #22, bug #32220 (project freefont):

I has two links:

To the present thread:

http://savannah.gnu.org/bugs/?32220

To Savannah:

http://savannah.gnu.org/

None none google drive link in your e-mail and none rejected e-mail message in my spam log.

cezary m. kruk <cmk>
Wed 12 Dec 2012 12:12:13 AM UTC, comment #26:

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.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 11 Dec 2012 11:05:58 PM UTC, comment #25:

Hi Steve,

Today I performed the additional tests. Each important fact is marked with a bullet.

I installed in Slackware Linux abiword (the word processor) and I printed the test page using my printer. The printout is bad. Abiword has nothing in common with [Apache] [Star|Open|Libre]Office[.org]. So the problem isn’t restricted to the descendants of StarOffice ‒ it affects probably all word processors available for Linux.

● The problem concerns also abiword 2.8.6 ‒ so it isn’t restricted to the StarOffice successors and probably infects the other word processors for Linux as well.

To show you the results I took the picture of the printout and I attached it to the present comment (I hope I’ll be able to do that). It isn’t the scan. I shoot the picture from hand in the ambient light and then I used GIMP to narrow the levels and to export JPG file to GIF one. As a result that file has the moderate size.

As you can see in FreeSerif and FreeSans the diaeresis accents in ËÏÜëü characters are lowered and moved slightly to the left. The similar but not the same problem affects FreeMono. In that font acute and grave accents in ĆŃÓŚŹ ÉÀÈÙ Regular uppercases are lowered, in ĆŃÓŚŹ ÉÀÈÙ Bold and BoldItalic uppercases are lowered and moved one character to the left, and in ćńóśź éàèù Bold and BoldItalic lowercases are moved one character to the left only. As a result the accents over ćńóś éàè seem to be in the right places though instead of é you see è because the accents from above the consecutive characters go over the previous characters. For the testing purposes I printed the similar sample putting the spaces between each consecutive characters and believe me that all the accents over these lowercases are moved to the left.

● The sample printout made with abiword 2.8.6 and Brother HL-5340D laser printer illustrates the discussed problem (see: abiword-2.8.6.gif)

I made also two screenshots of LibreOffice using OTF and TTF versions of GNU FreeFont. The results aren’t the same. X Window renders these two types of fonts in a different manner. With TTF fonts the kerning and the antialiasing of the text are much better than with OTF ones. Moreover when X Window can’t use the kerning and the antialiasing for the text it disables them in the case of the menu and the toolbars. As a result the menus and the toolbars have in both cases slightly different width. Personally I prefer menu and toolbars without kerning and antialiasing (the OTF version) but I prefer the text with kerning and antialiasing (the TTF version). Since it isn’t possible to have both at the same time I prefer the TTF version because I spend more time reading and writing the text than using menu and toolbars. Of course this is the matter of the taste and someone else can prefer the OTF version. I mounted the fragments of these two screenshots and I put it in a GIF file.

● TTF version of GNU FreeFont allows X Window to use the kerning and the antialiasing for the text, menu, and toolbars while OTF one forbids to use them (see: FreeFont-20120503-OTF-TTF.gif).

I printed the references.html file that you attached to the comment #18 using Firefox in Slackware. The problem persists in that case as well.

● Firefox 17.0.1 working in Slackware Linux 14.0 causes the same problems with printouts ‒ so the problem isn’t restricted to the different word processors but infects the entire X Window.

I didn’t mention X Window version used by both my Linux distributions.

● Slackware Linux 14.0 uses Xorg server 1.12.3 and Linux Mint 14 Nadia uses Xorg server 1.13.0 (the newest one).

I didn’t mention also the machine I use to run Slackware Linux or Linux Mint.

● I use IBM/Lenovo ThinkPad X60s (32-bit machine) to run Slackware Linux 14.0 or Linux Mint 14 Nadia (both in 32-bit versions).

As for the Linux distributions and the applications version numbers I reported them in the bulleted remarks from the comment #23 and the present one.

● If I don’t mention the program version number in some remark it assumes I refer to the version mentioned in some former remark. If I don’t mention the system it assumes I used Slackware Linux 14.0 because I use it by default. If I don’t mention the word processor it assumes I used LibreOffice Writer (the version dependent on the system according to the third remark from the comment #23).

***

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

It’d be nice indeed. I have to wonder whether I know someone owning such a printer. Unfortunately most of the people use ink printers or cheap laser printers (without PostScript). Moreover only HP and Brother provide Linux drivers for their printers by default. So it seems I should find someone with HP PostScript laser printer. It isn’t a piece of cake.

As I see the current SFD sources are here: http://svn.savannah.gnu.org/viewvc/trunk/freefont/sfd/?root=freefont. Should I download them and convert myself to TTF fonts or are there somewhere the current TTF files? I can perform such a conversion with FontForge but I prefer to use TTF files generated by the team because my conversion methods can differ from yours.

I hope I’ll be able to attach to that comment the pictures I made. If I’ll fail I send you these pictures by e-mail asking you to attach them to your consecutive comment as the samples for the other readers of our thread.

(file #27075, file #27076)

cezary m. kruk <cmk>
Tue 11 Dec 2012 11:06:15 AM UTC, comment #24:

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.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 11 Dec 2012 01:48:11 AM UTC, comment #23:

Hi Steve,

I spotted your suggestion. I don’t refuse to perform the tests and I don’t expect the other people will solve that problem instead of me. In January and February 2011 I worked hard testing and improving these fonts for my purposes. A few days ago I started a new round of the tests using the fonts released in May 2012.

I have two ideas: 1) to narrow and 2) to widen the problem:

1) Narrowing: as I reported in comment #17 GNU FreeFont 20120503 works better with my Brother HL-5340D laser printer than GNU FreeFont 20100919. So I intend to compare these two version of FreeFont using FontForge program. My idea is: the developers made some changes in some glyphs that improved the work of these fonts with my printer. I suppose that the analogous changes can improve the other glyphs. I’ll tests that and I’ll report the results here.

2) Widening: as I reported my Brother HL-5340D laser printer works bad with those fonts. I think it’d be interesting to know whether the other printers cause the similar problems. In my opinion it isn’t sensible to test different HP, Canon, Epson etc. printers. People use them and no-one reported the problem with FreeFont. I think that it’s reasonable to test the other Brother laser printers such as the printers from MFC series, the other printers from HL series, and the other HL-53xx printers such as HL-5350DN or HL-5370DW. Unfortunately I don’t own all these printers and I don’t know somebody owning them. So I asked LinuxQuestions.org guys whether someone owns such a printer and is willing to test GNU FreeFont.

***

As I see you don’t know too much about Linux so let me explain something. I use two Linuces: Slackware and Mint. Slackware is the oldest living Linux distribution. Mint is one of the newest ones and is the most popular Linux distribution according to http://distrowatch.com/. Slackware 14.0 is provided with 94 .ttf font files and 22 .otf font files. Mint 14 Nadia is provided with 195 .ttf font files (twelve of them are GNU FreeFont files taken from CVS) and none .otf font file. The official package with GNU FreeFont for Slackware is available at http://slackbuilds.org/repository/14.0/system/freefont/ and it uses freefont-ttf-20120503.zip source file. Linux Mint is based on Ubuntu ‒ the other very popular Linux distribution. Ubuntu is based in turn on Debian ‒ the Linux distribution almost as old as Slackware. So in the Linux world the TTF fonts are much more popular than the OTF ones at least in the case of these four notable Linux distributions.

In order to summarize the facts concerning that problem I put together the old and the new information. Each important fact is marked with a bullet.

● The problem concerns at least Brother HL-5340D laser printer.

I checked Brother website ‒ my printer uses up to date firmware version.

● My Brother HL-5340D uses current 1.18 firmware version.

The tests of the GNU FreeFont which I performed December 9 and reported in comment #17 I made using the newest Slackware Linux and LibreOffice. Today I repeated these tests using the newest Linux Mint and LibreOffice. In all cases my Brother laser printer produced bad results.

● My Brother HL-5340D prints GNU FreeFont 20120503 as well as the version 20120526 taken from CVS bad in Linux. I tested that in Slackware Linux 14.0 with LibreOffice 3.6.3.2 and Linux Mint 14 Nadia with LibreOffice 3.6.2.2.

LibreOffice is a successor of OpenOffice.org, and OpenOffice.org is a successor of StarOffice. Currently OpenOffice.org is developed as Apache OpenOffice. I installed in Slackware the newest version of that program. On the discussed printer it produces with GNU FreeFont exactly the same printouts as LibreOffice.

● That printer with that font used in Slackware Linux 14.0 with Apache OpenOffice 3.4.1 (formerly OpenOffice.org) produces invalid printouts as well.

To say that the mentioned problem is restricted to LibreOffice and OpenOffice is like to say that some other problem is restricted to Microsoft Office only. In the Linux world these programs are as important as Microsoft Office in the Windows world.

Next I installed in Slackware Linux the freefont-otf-20120503.tar.gz package and I tested the OTF version of FreeFont with LibreOffice and my laser printer. The result of the printing was perfect. So the problem is narrowed to the TTF version of FreeFont.

● LibreOffice prints OTF version of FreeFont well ‒ the problem appears with TTF version of FreeFont only.

At that point I could say that that problem is solved for me. Unfortunately it isn’t solved for the other Linux users and owners of some Brother printers because as I explained above the standard fonts used contemporary in different Linux distributions are TTF ones. Most Linux users aren’t aware that 1) some OTF fonts exist and 2) can work in a different manner than TTF fonts with some hardware.

As I reported previously LibreOffice prints TTF FreeFont bad but it exports these fonts to PDF files well and Acrobat Reader prints these PDF files well.

● The problem appears during printing the text ‒ the exported PDF files are OK.

I’m aware that printing PDF files differ from printing from LibreOffice. My point was the other. The valid printouts of PDF files exported from LibreOffice prove that LibreOffice doesn’t spoil these fonts ‒ it generates the valid PDF files. There’s something wrong with GNU FreeFont and Brother HL-5340D but everything is all right with LibreOffice and Apache OpenOffice.

I doubt that OpenOffice renders the fonts in a wrong way during the regular printing and renders the same fonts well during printing to PDF files. That program allows to select the printer language type. By default it uses PDF language. I tested it also with PostScript (level from driver), PostScript Level 1, PostScript Level 2, and PostScript Level 3. I wasted a few consecutive sheets of paper but the results were the same in all cases ‒ wrong.

● That printer produces wrong printouts independently of the language selected in OpenOffice: PDF, PostScript (level from driver), PostScript Level 1, PostScript Level 2, or PostScript Level 3.

Or maybe you can explain that wonder: the same program using its own rendering libraries produces the garbage on the printer and produces nice results in the PDF files?

In 2011 I installed Windows XP to test GNU FreeFont. According to the comment #6:

● Two drivers for Windows work well with FreeFont so the discussed problem doesn’t affect Windows XP unless you use the wrong driver (BR-Script3).

Don’t waste your time printing my examples on different printers other than Brother ones. I’m not sure that problem is restricted to Brother HL-5340D but I’m almost sure it doesn’t appears in the case of the printers made by the other manufacturers. Moreover I guess you perform these tests in Windows. It’s also the wasting of the time because as I reported in 2011 that that problem occurs in Linux only.

In Linux the problem appears with all available drivers for Brother HL-5340D laser printer:

1) LPR driver (hl5340dlpr-2.0.3-1.i386),
2) cupswrapper driver (cupswrapperHL5340D-2.0.4-1.i386),
3) PPD file.

These drivers are available on the Brother website (see: http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/download_prn.html).

I tested today all of them once again. In all cases the printouts were bad. By default I use PPD file because it’s plain text file while two other drivers include at least some proprietary binary files and the first driver includes the shared library as well.

● Brother HL-5340D produces bad results with all drivers for Linux provided by Brother ‒ I use by default the driver stored in the PPD file.

***

Soon I’ll compare GNU FreeFont 20100919 and 20120503. If I’ll find something interesting I’ll report that here.

cezary m. kruk <cmk>
Mon 10 Dec 2012 07:41:00 PM UTC, comment #22:

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.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Mon 10 Dec 2012 07:14:26 PM UTC, comment #21:

On correlating Cezary's report with the OpenTyp flags set in the files, it appears that the setting of the WE_HAVE_A_SCALE field is consistent with the occurrance of the effect. I guess this corresponds to "Use My Metrics" in the FontForge component info dialog.

In Mono, this flag is really redundant, and I could remove it everywhere. I have actually used it in places in the other faces (although inconsistently).

Of course, the right thing to do is find out which piece of software has the bug that trips over this.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Mon 10 Dec 2012 11:51:56 AM UTC, comment #20:

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

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Mon 10 Dec 2012 12:27:33 AM UTC, comment #19:

Hi Steve,

I tried my method with GNU FreeFont 20120503. Removing and replacing references repair acute and grave accents but spoils some glyphs using diaeresis accents so that method isn’t acceptable for you. You don’t have to prove that GNU FreeFont works well with different printers. It worked well for me when I used Canon PIXMA iP3600. I even can print these fonts properly using my Brother HL-5340D after exporting the document to PDF file. The problem appears only when I print the source file using LibreOffice.

To move the matter forward I asked LinuxQuestions.org guys to test these fonts with different Brother laser printers (see: http://www.linuxquestions.org/questions/linux-hardware-18/brother-laser-printer-and-gnu-freefont-4175440714/). Maybe someone would be willing to perform the tests and to confirm or deny my bug report.

cezary m. kruk <cmk>
Sun 09 Dec 2012 06:25:17 PM UTC, comment #18:

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, file #27062)

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Sun 09 Dec 2012 04:52:55 AM UTC, comment #17:

To compare GNU FreeFont 20100919, the same set of fonts repaired using the method described in the previous post, and GNU FreeFont 20120503 I tested FreeSerif, FreeSans, and FreeMono typefaces in Regular, Bold, Italic, and BoldItalic shapes using the following character set including Polish and French glyphs:

ĄĆĘŁŃÓŚŹŻąćęłńóśźż
ÉÀÈÙÂÊÎÔÛËÏÜÇéàèùâêîôûëïüç

I printed these sets of characters using Brother HL-5340D printer working with PPD file downloaded from the Brother website.

With old GNU FreeFont 20100919 that printer produces the invalid results for the following glyphs:

FreeSerif:
Regular: ĆŃÓŚŹćńóśź ÉÀÈÙËÏÜéàèùëü
Bold: none
Italic: ÀÙÏÜàèùü
BoldItalic: ËÏÜü

FreeSans:
Regular: ĆŃÓŚŹćńóśź ÉÀÈÙËÏÜéàèùëü
Bold: ËÏÜëü
Italic: ĆŃÓŚŹćńóśź ÉÀÈÙËÏÜéàèùëü
BoldItalic: ĆŃÓŹćńóź ÉËÏÜéëü

FreeMono:
Regular: ĆŃÓŚŹ ÉÀÈÙ
Bold: ĆŃÓŚŹćńóśź ÉÀÈÙéàèù
Italic: none
BoldItalic: ĆŃÓŚŹćńóśź ÉÀÈÙéàèù

With old GNU FreeFont 20100919 repaired automatically using the method mentioned in the previous post that printer produces the invalid results for the following glyphs:

FreeSerif:
Regular: ÏÜü
Bold: none
Italic: ÏÜü
BoldItalic: ÏÜü

FreeSans:
Regular: ÏÜü
Bold: ÏÜü
Italic: ÏÜü
BoldItalic: ÏÜü

FreeMono:
Regular: ÏÜ
Bold: ÏÜ
Italic: ÏÜ
BoldItalic: none

With new GNU FreeFont 20120503 that printer produces the invalid results for the following glyphs:

FreeSerif:
Regular: ËÏÜëü
Bold: none
Italic: ËÏÜëü
BoldItalic: ËÏÜëü

FreeSans:
Regular: ËÏÜëü
Bold: ËÏÜëü
Italic: ËÏÜëü
BoldItalic: ËÏÜëü

FreeMono:
Regular: ĆŃÓŚŹ ÉÀÈÙ
Bold: ĆŃÓŚŹćńóśź ÉÀÈÙéàèù
Italic: none
BoldItalic: ĆŃÓŚŹćńóśź ÉÀÈÙéàèù

So many glyphs are repaired in those fonts since version 20100919.

I didn’t tested the automatic method of repairing the glyphs with the new GNU FreeFont 20120503 yet so I can’t guarantee the results will be the same as with the previous version of these fonts.

cezary m. kruk <cmk>
Tue 08 Feb 2011 04:01:55 PM UTC, comment #16:

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

cezary m. kruk <cmk>
Mon 07 Feb 2011 11:34:22 PM UTC, comment #15:

Hi Steve,

After gathering all the information I reported so far I found the method to improve FreeFont typefaces. As a base font I used FreeFont 20100919 version.

1. In the first step I recreated references. In order to achieve that I opened each font, I selected all characters using Edit | Select | Select All option (Ctl+A), then I removed all references using Edit | Unlink Reference option (Ctl+U) and finally I restored references using Edit | Replace with Reference option (Alt+Ctl+Shft+F).

After that step the problems with FreeFont typefaces were restricted to three types of flaws:

● Invalid dieresis accents in all FreeSerif fonts except for FreeSerifBold, in all FreeSans fonts and in all FreeMono fonts except for FreeMonoBoldOblique – in the case of FreeMono the problem with dieresis accent was restricted to uppercase letters.

● Invalid DŽ, Dž and dž ligatures in all FreeSerif and FreeSans fonts.

● Invalid double grave accents in FreeSansOblique and FreeSansBoldOblique fonts.

Warning: As for double grave accent in my previous post I assumed by mistake it’s U+02F5 accent while in fact it’s U+030F accent.

2. In the second step I corrected dieresis accents. To achieve that I opened U+0308 accent (̈), I used Edit | Unlink Reference option (Ctl+U) and then I copied it as reference using Edit | Copy Reference option (Ctl+G). Next I replaced dieresis accents in all characters that use them by opening the character, putting guide lines, removing dieresis accent, pasting new accent with Edit | Paste option (Ctl+V) and placing it in the position of the old accent. Original accents were referenced as “dieresis”. New accents are referenced as “diaeresiscomb”.

3. In the third step I corrected DŽ, Dž and dž ligatures. By default they are referenced as combinations of letters D or d and Ž or ž. To correct them it was enough to reference them as combinations of DZ, Dz or dz ligatures and U+02C7 accent (ˇ). So I put the appropriate guide lines, then I copied ligatures as references using Edit | Copy Reference option (Ctl+G) and pasted them on the place of the original characters with Edit | Paste option (Ctl+V) and finally I copied mentioned U+02C7 accent (ˇ) using Edit | Copy Reference option (Ctl+G), pasted it on the place of the original accents with Edit | Paste option (Ctl+V) and put it in the correct place. Some of DZ, Dz or dz ligatures are narrower than DŽ, Dž and dž ligatures so it isn’t enough to put the new accent on the place of the old one but in some cases it’s necessary to correct slightly its position.

4. In the fourth step I corrected double grave accents. As I mentioned above it’s U+030F accent (̏). To correct the printing results it’s enough to open that accent and to use Edit | Unlink Reference option (Ctl+U). The characters using it still have “grave grave” references but give good results on printouts.

In result my printer prints all characters from the selected ranges perfectly.

In my opinion performing such manipulations on the original FreeFont would improve it. I suggest you to try that on a few characters and then check the printouts with the printers available for you.

Bye,
CMK

Anonymous
Sun 06 Feb 2011 09:06:32 PM UTC, comment #14:

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

Anonymous
Thu 27 Jan 2011 06:57:46 PM UTC, comment #13:

CMK,

No, I'm afraid you still don't understand, but I think we have all the information we need at this point, and we can take the discussion off-line.

Cheers!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Thu 27 Jan 2011 01:59:59 PM UTC, comment #12:

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

Anonymous
Thu 27 Jan 2011 01:21:39 PM UTC, comment #11:

Hi,

As for Linux drivers they offer an access to the basic set of the printer settings. Among emulation modes there is HP LaserJet Mode supporting PCL6 language. According to the User’s Guide there are two settings of the driver: in the first the printer chooses from: HP LaserJet, BR-Script3 and EPSON FX-850; in the second the printer chooses from: HP LaserJet, BR-Script3 and IBM ProPrinter XL. So in both cases the printer chooses the appropriate mode itself. I doubt the user can have an influence on that, though maybe is possible to cheat the printer using some HP LaserJet driver. I’ll test that.

As for invalid characters I’ll compare yours and mine versions of FreeSerif typefaces in order to discover why some characters are printed bad and the other are printed good. That’s about the typefaces’ side of the problem. As for the printer’s side of the problem I suppose it lays in an invalid substitutions of some accents. Some errors are obviously caused by mentioned bad references in the typefaces and some errors are apparently caused by bad printer firmware.

As I declared before I’ll do these tests the next week so be patient and wait a while.

Cheers

Anonymous
Wed 26 Jan 2011 08:39:17 PM UTC, comment #10:

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!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Wed 26 Jan 2011 08:31:17 PM UTC, comment #9:

Hi cmk

I'll try the driver, if I can.

I don't know what you're referring to with
" some characters from FreeFont 20100919 which cause printing problems have unreferenced glyphs instead of referenced accents"
This sounds like you misunderstand the nature of the problem.

This problem you reported is not the fault of FreeFont at all. It is purely and simply a driver bug. I have yet to see an "invalid accent" in this regard. The references in FreeFont did not "cause the problem", any more than a door causes a drunk to run into it. They were technically correct, and working well for drivers that were not misbehaving.

The changes I have made were only to make the references more consistent among the faces. The obvious way to do that also happens to make the driver bug appear less often. As to why the inconsistency occurred: well, I'm the only person responsible --hell, probably I did it.

As to the Unicode ranges I mentioned, you can find them here:
http://www.unicode.org/charts/#scripts
The grave and acute accent occurs in several ranges for rather different reasons, and that reasoning itself is often more historical than sound. Other accents only occur in one range. This should have nothing to do with the driver's ability to use a referenced glyph however.

Thanks again!
Happy Birhday, CMK!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Wed 26 Jan 2011 01:42:22 AM UTC, comment #8:

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

Anonymous
Tue 25 Jan 2011 10:03:42 PM UTC, comment #7:

Thanks for your very thorough report!

I'm unclear on which "Linux" driver you're referring to. That's very interesting. Is this a Brother driver for Linux, or from a Linux distro?

As to reporting the bug: Frankly I had in mind that you would report it. I don't even have access to a device that shows the bug. (Also, I don't know why they would listen to a free software developer rather than a customer...) Why don't you go ahead and try to report the bug. If there's a way for me to add my voice to yours, or provide technical assistance, I'm glad to do so.

It sounds like the bug consists of: the driver freaking out in the presence of accents as glyph references from the Spacing Modifier Letters or Combining Diacritics ranges. You describe several different effects. There are more: accents as references are used in other ranges such as Cyrillic and Greek.

I'll go ahead with similar modifications for the rest of the FreeSerif faces. Mostly this consists of replacing references to accents in the Spacing Modifier Letters or Combining forms to the Latin range accents, when they exist. (Just committed changes to FreeSerif.sfd FreeSerifItalic.sfd)

This can't always be done however: the dotaccent, circumflex, caron, breve etc are not in the Latin range, and this driver bug will probably continue to manifest itself. (This accounts for the difference in results between our two modifications.) I'm not willing to unlink all the references in the font to brush some third-party bug under the rug. The references are there for good reasons, and making real bugs disappear rather than fixing them is unhygenic.

Sorry about the forest!

Cheers!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 25 Jan 2011 05:24:35 PM UTC, comment #6:

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

Anonymous
Mon 24 Jan 2011 11:09:49 PM UTC, comment #5:

Hello Steve,

I’m glad you consider to alert Brother about invalid drivers and possible firmware bugs. The voice of your team is much stronger than the voice of an individual user so maybe Brother guys will improve these drivers.

As for Windows I stated PCL5 driver provided with the printer works better than described in User’s Guide and mentioned before BR-Script3 printer driver. After the installation of Windows PCL5 driver the problem of invalid characters was reduced to dieresis accent. I tested only one character – namely “Ï” – but I suppose that problem concerns more characters. Windows PCL5 driver has that problem with original FreeFont 20100919 as well as with FreeFont version I modified for my purposes. In fact it isn’t very serious problem because Windows standard driver works nice with both original and mine FreeFont typefaces.

As for Linux the only way to avoid the problem – with the exception of “Ï” character and maybe some other characters which I didn’t tested – is to use FreeFont version I modified.

In fact invalid Windows driver isn’t my problem. I installed Windows three days ago just to test my new printer when I encountered the problems concerning printing with Linux. Finally I solved these problems by restoring the appropriate references in all FreeFont typefaces. So I don’t need Windows again.

The sad part of that story is I wasted a little forest during all these printing tests with Linux and with Windows.

As for your changes in FreeSerif typeface I’ll test it tomorrow or rather today because it’s after the midnight now.

Cheers,
cezary m. kruk

Anonymous
Mon 24 Jan 2011 10:59:42 PM UTC, comment #4:

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.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Mon 24 Jan 2011 08:49:13 PM UTC, comment #3:

Well Hello cmk

I'm not sure who I can send your login complaint to... I'll think about it.

Regarding the main issue, first I think there is nothing "invalid" about using a glyph from either range of marks. Indeed, it is possible to assemble a glyph from references whose code points aren't even encoded.

This in itself is no FreeFont problem--it is a printer driver or firmware bug, and we should alert the company of the problem. You're doing a great job of gathering info.

On the other hand, I have noticed that FreeFont is inconsistent as to which ranges it draws accents from. This is not optimal. I'll think about improving that.

Cheers!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Mon 24 Jan 2011 04:54:10 PM UTC, comment #2:

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 http://www.bigfoot.com. Unfortunately I didn’t get an e-mail allowing me to finalize the registration process. My e-mail address on http://www.bigfoot.com isn’t a real address but an alias to the address on http://www.wp.pl. As I guess your system recognizes that alias as invalid address or recognizes http://www.bigfoot.com as spammers’ domain. In fact since 1997 when I registered that e-mail alias http://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 http://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

Anonymous
Mon 24 Jan 2011 08:46:21 AM UTC, comment #1:

Hi, Anonymous!

(By the way, to be updated about the status of your report, it is better to register an account.)

From what I can tell, this is more of a printer driver bug than a bug with the font.

However, if there is some simple alteration I can make to alleviate the problem, I will do so. But I need to see the problem myself. I suppose I could try downloading this driver: Will I see the results in the PDF file resulting from "print to file"?

Cheers!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Sun 23 Jan 2011 11:56:52 PM UTC, original submission:

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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #27075:  abiword-2.8.6.gif added by cmk (296kB - image/gif)
file #27061:  references.html added by Stevan_White (1kB - text/html - Photo of test done on my printer.)
file #27062:  Canon-iP1000-test.jpeg added by Stevan_White (170kB - image/jpeg - Photo of test done on my printer.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by cmk (Posted a comment)
  • -unavailable- added by Stevan_White (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 12 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 13 Dec 2012 12:56:10 AM UTCcmkAttached File-=>Added FreeFont-20121211-diacritics.gif, #27087
      Attached File-=>Added FreeFont-20121211-punctuation.gif, #27088
      Attached File-=>Added FreeMono-CourierNew-LiberationMono.gif, #27089
    Tue 11 Dec 2012 11:05:58 PM UTCcmkAttached File-=>Added abiword-2.8.6.gif, #27075
      Attached File-=>Added FreeFont-20120503-OTF-TTF.gif, #27076
    Mon 10 Dec 2012 12:10:35 PM UTCStevan_WhiteCategoryoverall font problem=>individual character(s)
      Item Groupbulk text appearance poor=>printing
    Sun 09 Dec 2012 06:25:17 PM UTCStevan_WhiteAttached File-=>Added references.html, #27061
      Attached File-=>Added Canon-iP1000-test.jpeg, #27062
    Tue 25 Jan 2011 10:03:42 PM UTCStevan_WhiteStatusNeed info=>Proceeding
    Mon 24 Jan 2011 08:46:21 AM UTCStevan_WhiteStatusNone=>Need info
      Assigned toNone=>Stevan_White

    Back to the top


    Powered by Savane 3.1-cleanup