Bug 1401

Just a little comment: since adding glyphs from KOI8-encoded fonts to iso10646-1
ones can be tricky, there are more appropriate fonts, which contain cyrillics
already as subset of 10646-1, at
http://www.inp.nsk.su/~bolkhov/files/fonts/cyr-rfx/srctgz/cyr-rfx-iso10646-0400-1.1.bdfs.tgz

I produced all the *-iso10646-1 versions of the old BDF core fonts. Merging in
your Cyrillic glyphs into the Adobe BDF fonts is still on my todo list (along
with adding in some B&H extensions that I received from Charles Bigelow a while
ago, plus various Unicode 4.0 extensions that I received recently). Thanks for
the reminder.

An open and still unresolved question is the licence issue for these ancient
Adobe pixel fonts (Helvetica, etc.):

Are we still allowed to call these fonts "Adobe" after we have added lots of
glyphs that were not originally designed by either Adobe or B&H? You are trying
to add Cyrillic glyphs to Latin-only fonts that never did contain any Cyrillic
glyphs. When I did the ISO10646-1 extension, I simple reused and superimposed
glyphs that were already in the fonts. I did not add completely new glyphs,
which is what you suggest we should do here.

In practice, I don't believe that any original suppliers worries any more about
licence issues of ancient bitmap fonts, so I suggest that we just do it, unless
anyone here seriously objects.

What I will do is to merge these fonts properly with the ISO10646-1 fonts, and
from there various 8-bit fonts (including KOI-8R) can be automatically extracted
using the existing facilities. We should certainly not add these as separately
maintained 8-bit fonts.

> What I will do is to merge these fonts properly with the ISO10646-1 fonts,
> and from there various 8-bit fonts (including KOI-8R) can be automatically
> extracted using the existing facilities. We should certainly not add these
> as separately maintained 8-bit fonts.

Yes, this is quite clear.  I'm sorry for a bit misleading bugreport title.  Of
course, the intent was/is to add cyrillic glyphs to 10646-1 fonts.

Regarding license issues: I fully agree with you that probably original
suppliers don't care about these ancient fonts.

And all Adobe fonts (Courier, Helvetica, Times) contain a license in COMMENT
clause, which in particular states that

"Permission to use, copy, MODIFY, distribute and sell this software
and its documentation for any purpose and without fee is hereby
granted..."

So, at least those fonts allow any manipulations -- both computer-authored (as
are yours) and human-made (as adding cyrillics).

And, if there are any doubts -- why can't we implement your 2-years old idea to
rename all these fonts to "-XFree86-something" or "-Xorg-something" and create a
 coherent set of aliases with names "-Adobe-*" and "-B&H-*".

Yes, but the original suppliers may care about the use of their name in
the name of the font, unless they have blessed their use.

Remember, Adobe, B&H, Bitstream's most important single asset is their
reputation....  Changing the primary name while providing aliases from the
names with the vendor's name in them is probably prudent, for the antique
fonts.

In the Bitstream case, we should attempt to work with them when we add glyphs.

Lack of explicit approval/license does not give an implied approval/license
to make changes.  While I absolutely agree that this stuff is old enough that
most of these companies probably do not care, it is a legal landmind to
/assume/ that that will be the case.  Not only X.Org/XFree86.org take the
risks, but all vendors shipping the codebases from either project.  Please
get the appropriate legally binding approval from Adobe, B&H, or whoever
before committing any changes to the fonts, in order to ensure that we do not
have fonts in the source tree which have legal ambiguity.

This may be considered by some people to be annoying red tape to have to
jump through, but in today's legal atmosphere, I consider it to be a very
important legal requirement.

Note:  I am not speaking authoritatively for X.Org, just offering a personal
opinion as a community member who is strongly concerned about open source
intellectual property issues in general.

Hopefully someone at X.Org can offer an authoritative response though.

Thanks for investigating these issues!

Okay, so, the consensus is that changing the -FOUNDRY-FAMILY part and making
appropriate aliases is enough to escape any legal problems.

The following scheme looks sufficient:

-Adobe-Times
   -> -Xorg-Dutch
-Adobe-Helvetica
   -> -Xorg-Swiss
-Adobe-Courier
   -> -Xorg-Courier
-Adobe-New Century Schoolbook
   -> -Xorg-Nuovo Secolo Libro
-B&H-Lucida*
   -> -Xorg-Serene*

RATIONALE:

"Dutch" and "Swiss" (without numbers 8NN and 7NN) are copyright-free equivalents
of "Times" and "Helvetica".

"Courier" name, if memory serves me right, is in public domain.

I couldn't find an appropriate analog for "New Century Schoolbook", so gave it a
voluntary italian translation.

Regarding "Lucida": in 2000, when I've just finished cyrillization of X fonts
and was ready to release them, I had a brief correspondence with Chuck Bigelow.
He confirmed that distributing modified versiona under "B&H" or "Lucida" names
is NOT appropriate, but upon changing these names everything IS OK.  So, in
CYR-RFX/fonts-KOI8-R these fonts are called "Serene" and "SereneTypewriter".

Assigning this bug to myself.

If we rename the fonts into -Xorg-*, we would still have to provide -Adobe-*
aliases for them, simply for backwards compatibility. Is an XLFD alias a legally
sufficient distinction?

Calling them

  -Xorg-Times-*
  -Xorg-Helvetica-*
  -Xorg-Courier-*
  ...

would certainly be far less obscure for most users.

Where exactly did you hear about the legal status of these font names? The only
legal possibility of protecting such names that I am aware of is to register
them as a trademark in lots and lots of countries. Has this been done for these
fonts names, and if so by whom, in which countries, and when?

While I like sound of the Dutch/Swiss/etc. names, they are a bit obscure. And
who guarantees us that they have not been trademarked for some other font
already? How about the aliases that the ISO chose in the CGM standard for Times,
Helvetica and Courier fonts (the metrics of which are defined in the CGM
standard), namely -- if I recall correctly -- Serif, Sans and Mono? It seems
SuSE has used these same names for some outline fonts in their distribution.

> If we rename the fonts into -Xorg-*, we would still have to provide
> -Adobe-* aliases for them, simply for backwards compatibility.

Of course.  That's what was done in CYR-RFX for B&H fonts.

> Is an XLFD alias a legally sufficient distinction?

Yes.  The alias is like saying "the font X is similar to font Y" -- that's not a
subject to copyright and trademarking.  And that's exactly the situation which
lasts for 4 years with Serene fonts in CYR-RFX, which are aliased via Lucida names.

> Calling them -Xorg-Times-*, -Xorg-Helvetica-*, -Xorg-Courier-*, ...
> would certainly be far less obscure for most users.

Agreed.  But if there are "Times", "Helvetica", etc. provided (nobody cares that
these are just aliases), 99% of users will be satisfied.

> Where exactly did you hear about the legal status of these font names?

Well, IANAL, but I got the feeling that these names are more or less
trademarked, when skimmed through various fonts suppliers' sites.

BTW, the helv*.bdf and tim*.bdf fonts contain the following phrases:

Helvetica is a trademark of Linotype-Hell AG and/or its subsidiaries.
Times is a trademark of Linotype-Hell AG and/or its subsidiaries.

As I understand, that's why "Swiss" and "Dutch" names are used by companies
other than Linotype/Monotype.

Well, "Times" is more questionable than "Helvetica", since it wass derived from
the name of newspaper (in 1930s, AFAIR), and there are many diffirent variations
by various companies (Times Roman, Times New Roman, TimesMT, etc.).

IMHO, selecting names different from original ones will give us 100% protection
from copyright problems.

Markus, do you need any help with integrating cyrillics?  If so -- please, don't
hesitate to ask either me or Leonid -- we'll be glad to provide any support
required.  

(This absence of cyrillics among regular fonts has been a big PITA for years,
and still feeds us with lots of problems :-)

A KOI8-R repertoire extension of the ancient Adobe and B&H proportional BDF
pixel fonts seems no longer really necessary. This feature request has now
become a rather low priority, because progress with the use of client-side
TrueType font technology has rendered proportional BDF fonts mostly obsolete,
especially for the KOI8-R repertoire, which is now covered well by much better
available WGL4 TrueType fonts.

Most modern X11 applications that use proportional fonts (Firefox 1.0 and all
the other Mozilla suit tools, all the KDE and GNOME tools and anything else
built on top of Qt of GTK+, Open Office, many other older programs, even the
good old fvwm2 window manager!) are now by default using client-side FreeType
rendering of TrueType fonts.

In addition, many modern OS distributions make it extremely easy for an
installer to load the "TrueType core fonts for the Web" that Microsoft has
licensed for free redistribution (as long as they are not modified or sold as
part of a product).

So X11 users now have easy access to high-quality fonts such as Arial and Times
New Roman that cover the full WGL4 repertoire, which is a superset of a KOI8-R
and ISO 8859-{1,2,3,4,5,7,9,10,13,15}. These are very easy to install, for
example under SuSE Linux using the "fetchmsttfonts.sh" script that is offered by
the YaST Online Update tool, and equivalent tools in other modern
operating-system distributions.

Fact is that on a typical 2004 Linux distribution, KOI8-R characters work
already out of the box today from TrueType fonts.

http://corefonts.sourceforge.net/
http://volker.dnsalias.net/linux/msttcorefonts.html

Markus, there still IS a need for cyrillics in bitmapped 10646-1 fonts.  There 
are at least two reasons. 

First, at small sizes (less than 16-20) the legibility of hand-tuned bitmapped 
fonts is higher. 

Second, the vector fonts which are available with cyrillics, are simply not 
adequate. Yes, there are "free" Micro$oft fonts, but they a) have uncertainties 
with their licence, and b) are not-so-good -- for example, "arial italic" is 
just neither italic, nor oblique -- it is an awful mixture.

And those cyrillic-enabled fonts which come with X11 (or are bundled with 
distros) are not on par with "good old adobe fonts": it seems that they just 
have a different "font repertoire".  The best of X11 vector fonts (e.g. Luxi) 
don't have cyrillics at all (and it is unlikely to change).  And those "vector 
cyrillics" which are present, are TOO FAT.

I'm in Japan now, far away from my office and my computer, so I can't provide 
screenshots right now.  But beleive me -- currently readily-available-from-
distro fonts are NOT adequate.

I second that. CYR-RFX is the main cyrillic font on my systems. 
Please find out a way to keep Adobe Helvetica, Times and Courier, they are still
indispensable.

Markus,

Probably you believe, that eventually this problem will become outdated (as
users go to FreeType rendering) and it will not be necessary to solve it.
Unfortunately, it is not true.

As you see, time goes, but users still require this issue to be resolved. And
I'm  another one who vote for it.

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

> there still IS a need for cyrillics in bitmapped 10646-1 fonts

> at small sizes (less than 16-20) the legibility of hand-tuned bitmapped 
> fonts is higher

This days the issue yet not gone. Hence ping... :)

I still have to complete the ordinary fonts by the ones from
ftp://ftp.asplinux.org/pub/sources/SRPMS.11.2/fonts-ISO10646-1-0.4-0.3asp.src.rpm

at least to see the good Helvetica on my favourite 1024x768 monitor...

Can this please get a status update

Seems nothing changed yet.

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.