bug#10399: [PATCH] Document win32 font backends

bug#10399: [PATCH] Document win32 font backends

[Daniel Colascione]

---
 doc/lispref/frames.texi |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/doc/lispref/frames.texi b/doc/lispref/frames.texi
index dad1f28..e4338c8 100644
--- a/doc/lispref/frames.texi
+++ b/doc/lispref/frames.texi
@@ -888,7 +888,10 @@ and bar becomes a narrower bar).
 A list of symbols, specifying the @dfn{font backends} to use for
 drawing fonts in the frame, in order of priority.  On X, there are
 currently two available font backends: @code{x} (the X core font
-driver) and @code{xft} (the Xft font driver).  On other systems, there
+driver) and @code{xft} (the Xft font driver).  On Windows, there
+are currently two available font backends: @code{gdi} and
+@code{uniscribe}.
+On other systems, there
 is only one available font backend, so it does not make sense to
 modify this frame parameter.
 
-- 
1.7.5.1

bug#10399: [PATCH] Document win32 font backends

[Juanma Barranquero]

On Thu, Dec 29, 2011 at 15:06, Daniel Colascione <dancol@dancol.org> wrote:

> -driver) and @code{xft} (the Xft font driver).  On other systems, there
> +driver) and @code{xft} (the Xft font driver).  On Windows, there
> +are currently two available font backends: @code{gdi} and
> +@code{uniscribe}.
> +On other systems, there

Committed, thanks.

    Juanma

bug#10399: [PATCH] Document win32 font backends

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 29 Dec 2011 17:21:08 +0100
> Cc: 10399-done@debbugs.gnu.org
> 
> On Thu, Dec 29, 2011 at 15:06, Daniel Colascione <dancol@dancol.org> wrote:
> 
> > -driver) and @code{xft} (the Xft font driver).  On other systems, there
> > +driver) and @code{xft} (the Xft font driver).  On Windows, there
> > +are currently two available font backends: @code{gdi} and
> > +@code{uniscribe}.
> > +On other systems, there
> 
> Committed, thanks.

Please add there an @xref to "(emacs)Windows Fonts", where there are
more details about that.

Thanks.

bug#10399: [PATCH] Document win32 font backends

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

On 12/29/11 8:57 AM, Eli Zaretskii wrote:
>> From: Juanma Barranquero <lekktu@gmail.com>
>> Date: Thu, 29 Dec 2011 17:21:08 +0100
>> Cc: 10399-done@debbugs.gnu.org
>>
>> On Thu, Dec 29, 2011 at 15:06, Daniel Colascione <dancol@dancol.org> wrote:
>>
>>> -driver) and @code{xft} (the Xft font driver).  On other systems, there
>>> +driver) and @code{xft} (the Xft font driver).  On Windows, there
>>> +are currently two available font backends: @code{gdi} and
>>> +@code{uniscribe}.
>>> +On other systems, there
>>
>> Committed, thanks.
> 
> Please add there an @xref to "(emacs)Windows Fonts", where there are
> more details about that.

Doing that makes sense.

Since we're on the subject of Windows font backends: is it worth
creating a DirectWrite backend? It does a better job of inter-character
spacing and rendering at small sizes than Uniscribe does.

https://bugzilla.mozilla.org/show_bug.cgi?id=517642

https://blog.mozilla.com/nattokirai/2009/10/22/better-postscript-cff-font-rendering-with-directwrite/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

bug#10399: [PATCH] Document win32 font backends

[Eli Zaretskii]

> Date: Thu, 29 Dec 2011 09:16:16 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: Juanma Barranquero <lekktu@gmail.com>, 10399@debbugs.gnu.org
> 
> Since we're on the subject of Windows font backends: is it worth
> creating a DirectWrite backend? It does a better job of inter-character
> spacing and rendering at small sizes than Uniscribe does.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=517642
> 
> https://blog.mozilla.com/nattokirai/2009/10/22/better-postscript-cff-font-rendering-with-directwrite/

Looks like it has only C++ bindings?  One of the comments on MSDN
says:

  DirectDraw header file is not compatible with C programming language
  and can only be included in C++ code. However, C-style redeclaration
  of contents in this header file alone (excluding other header files it
  includes), will succeed in resolving the issue.

Also, I see no dwrite.h header in the MinGW runtime and w32api
distributions, and no lib*.a import libraries for dwrite.dll.  Am I
missing something?

bug#10399: [PATCH] Document win32 font backends

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

On 12/31/11 2:56 AM, Eli Zaretskii wrote:
>> Date: Thu, 29 Dec 2011 09:16:16 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: Juanma Barranquero <lekktu@gmail.com>, 10399@debbugs.gnu.org
>>
>> Since we're on the subject of Windows font backends: is it worth
>> creating a DirectWrite backend? It does a better job of inter-character
>> spacing and rendering at small sizes than Uniscribe does.
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=517642
>>
>> https://blog.mozilla.com/nattokirai/2009/10/22/better-postscript-cff-font-rendering-with-directwrite/
> 
> Looks like it has only C++ bindings?  One of the comments on MSDN
> says:
> 
>   DirectDraw header file is not compatible with C programming language
>   and can only be included in C++ code. However, C-style redeclaration
>   of contents in this header file alone (excluding other header files it
>   includes), will succeed in resolving the issue.

DirectWrite is COM, and all COM facilities can be used by plain C.

The C compatibility issue arises from a problem with the header for
the COM interface produced by the IDL compiler (probably, nobody tried
to actually use DirectWrite from C before shipping.)  This problem
doesn't prevent our using DirectWrite from C: as the MSDN comment
indicates, the declarations just need to be extracted and rephrased as
standard C.

> Also, I see no dwrite.h header in the MinGW runtime and w32api
> distributions, and no lib*.a import libraries for dwrite.dll.  Am I
> missing something?

No. Either these packages would need to be updated to include
DirectWrite or we'd need to just include declarations for the
appropriate functions and interfaces ourselves.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

bug#10399: [PATCH] Document win32 font backends

[Eli Zaretskii]

> Date: Sat, 31 Dec 2011 03:04:42 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: lekktu@gmail.com, 10399@debbugs.gnu.org
> 
> The C compatibility issue arises from a problem with the header for
> the COM interface produced by the IDL compiler (probably, nobody tried
> to actually use DirectWrite from C before shipping.)  This problem
> doesn't prevent our using DirectWrite from C: as the MSDN comment
> indicates, the declarations just need to be extracted and rephrased as
> standard C.
> 
> > Also, I see no dwrite.h header in the MinGW runtime and w32api
> > distributions, and no lib*.a import libraries for dwrite.dll.  Am I
> > missing something?
> 
> No. Either these packages would need to be updated to include
> DirectWrite or we'd need to just include declarations for the
> appropriate functions and interfaces ourselves.

If a MinGW build of Emacs can use DirectWrite, and if there will be no
copyright issues with providing the missing headers and interface
libraries, then feel free to work on adding DirectWrite support to
Emacs.  Thanks in advance.

bug#10399: [PATCH] Document win32 font backends

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On 12/31/11 3:22 AM, Eli Zaretskii wrote:
> If a MinGW build of Emacs can use DirectWrite, and if there will be no
> copyright issues with providing the missing headers and interface
> libraries, then feel free to work on adding DirectWrite support to
> Emacs.  Thanks in advance.

What exactly is the legal situation surrounding headers? Would copying
and modifying declarations from the Microsoft headers or MSDN be
acceptable, considering that there is really only one way to describe
what a function is called and what parameters it takes? If not, how
exactly would one create untainted declarations?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

bug#10399: [PATCH] Document win32 font backends

[Eli Zaretskii]

> Date: Sat, 31 Dec 2011 03:41:46 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: lekktu@gmail.com, 10399@debbugs.gnu.org
> 
> What exactly is the legal situation surrounding headers?

Sorry, I have no idea.  I was wondering about that myself.

> Would copying and modifying declarations from the Microsoft headers
> or MSDN be acceptable, considering that there is really only one way
> to describe what a function is called and what parameters it takes?
> If not, how exactly would one create untainted declarations?

One way of finding out the answers would be to ask how MinGW (or is it
Cygwin?) produces the headers in the w32api distribution, and how they
avoid the copyright issues when they do.

bug#10399: [PATCH] Document win32 font backends

[Óscar Fuentes]

Daniel Colascione <dancol@dancol.org> writes:

> On 12/31/11 3:22 AM, Eli Zaretskii wrote:
>> If a MinGW build of Emacs can use DirectWrite, and if there will be no
>> copyright issues with providing the missing headers and interface
>> libraries, then feel free to work on adding DirectWrite support to
>> Emacs.  Thanks in advance.
>
> What exactly is the legal situation surrounding headers? Would copying
> and modifying declarations from the Microsoft headers or MSDN be
> acceptable, considering that there is really only one way to describe
> what a function is called and what parameters it takes? If not, how
> exactly would one create untainted declarations?

IIRC, copying from the headers is not acceptable, as Microsoft's SDK
license bans that. Copying from MSDN is correct, because it is publicly
available documentation.

As Eli suggests, asking on the MinGW ml would provide definite answers,
as creating headers for the SDK/CRT/etc is what MinGW does all the time.