Re: Question on DSIG and head flag 11

Vladimir and others,

Should the 'DSIG' table, as a whole, be removed, or should only any digital signature that is present be removed from the table? Changes to the 'sfnt' resource affect the validity of the digital signature, not the table as a whole. I raise this question because some environments (Windows is one example, I think) use the mere presence of the 'DSIG' table to assign the correct icon to OpenType/CFF fonts. It is possible to have a completely valid 'DSIG' table that includes zero (0) digital signatures, which can be referred to as a "stub" table.

The open source OpenType/CFF fonts that I have built include a 'DSIG' table with zero signatures. The size of such a table is a mere eight bytes, and the following is its ttx XML snippet:

  <DSIG>
    <tableHeader flag="0x0" numSigs="0" version="1"/>
  </DSIG>

Anyway, this is something to consider as an alternative to simply removing the 'DSIG' table.

Regards...

-- Ken

> On Jul 6, 2015, at 7:44 AM, Levantovsky, Vladimir <vladimir.levantovsky@monotype.com> wrote:
> 
> Hi all,
> 
> Sorry for delayed response, I was 'technically' on vacation last week as well, and had very limited access to email.
> With my WG chair hat off, I would like to speak in favor of keeping things in WOFF2 as they are today and having the DSIG table removed when the font goes through woff2 conversion process. 
> 
> I do realize that in some specific circumstances the case could be made that the conversion process doesn't invalidate the DSIG data, but special case handling is prone to errors and could do more harm than good. (I'm really not sure if there is anything 'good' comes from having DSIG - like I mentioned once in the past, I believe having the DSIG provides no benefits and only creates a false sense of security.) Besides, as you are aware, we have recently decided to modify the spec and reuse the remaining flags as a versioning mechanism to make the spec extensible and allow us to easily introduce additional transforms in the future. The immediate need for this was the 'hmtx' transform proposal but we also considered other things such as e.g. CFF de-subroutinization as a way to improve overall compression gains for CFF fonts. The possibility of introducing new optimizing transforms in the future doesn't bode well with the special case DSIG handling - I'd rather have it removed and have the proper flag set (as we do today) than having to reinstate special DSIG handling and have to come back and deal with it again when another transform is introduced in the future.
> 
> Cheers,
> Vlad
> 
> -----Original Message-----
> From: Ken Lunde [mailto:lunde@adobe.com] 
> Sent: Monday, June 29, 2015 12:49 PM
> To: Cosimo Lupo
> Cc: public-webfonts-wg@w3.org
> Subject: Re: Question on DSIG and head flag 11
> 
> In the back of my mind I figured that you were the one who reported the otf2otc issue, but I was too lazy to go back and check (I am technically on vacation, and Adobe is also shut down this week). ;-)
> 
> -- Ken
> 
>> On Jun 29, 2015, at 10:38 AM, Cosimo Lupo <cosimo.lupo@daltonmaag.com> wrote:
>> 
>> Thanks for reminding me, Ken.
>> It was actually me who sent that pull request, under my github 
>> nickname... :)
>> https://github.com/adobe-type-tools/afdko/commit/59a5bbc85adad8398c840
>> 1676b319d37b9f06c16
>> 
>> 
>> On 29 June 2015 at 17:35, Ken Lunde <lunde@adobe.com> wrote:
>> Cosimo Lupo,
>> 
>> Examples of fonts whose tables are not aligned to four-byte boundaries are the OpenType/CFF Collections (OTCs) in Versions 1.000 and 1.001 of Source Han Sans (and, by extension, Noto Sans CJK). The AFDKO otf2otc script wasn't doing this, though the tables in the source OpenType/CFF fonts were aligned to four-byte boundaries. Anyway, the otf2otc was adjusted in early March, and Version 1.002 and beyond (Version 1.004) do not have this issue (though it didn't seem to matter).
>> 
>> Regards...
>> 
>> -- Ken
>> 
>>> On Jun 29, 2015, at 10:27 AM, Cosimo Lupo <cosimo.lupo@daltonmaag.com> wrote:
>>> 
>>> Sorry about that. I have yet to see an OpenType font with table offsets which are not long-aligned. My experience with fonts is relatively short, so perhaps I tend to take too literally statements like this one from the OT spec:
>>> 
>>>> the length of a table must be a multiple of four bytes. In fact, a font is not considered structurally proper without the correct padding. All tables must begin on four byte boundries, and any remaining space between tables is padded with zeros.
>>> 
>>> Never mind then. Apologies for raising this again.
>>> 
>>> C.
>> 
>> 
>> 
>> 
>> --
>> Cosimo Lupo
>> Font Development
>> 
>> Dalton Maag Ltd
>> 9th Floor, Blue Star House,
>> 234-240 Stockwell Road
>> London SW9 9SP United Kingdom
>> Direct: +44 7825 324360
>> London Office: 44 20 7924 0633
>> 
>> Passionate about type?
>> Try before you buy - download our free trial fonts Sign up to our 
>> newsletter Follow us on Twitter
>> 
>> 
>> 
>> Registered office: 
>> Mutfords, Hare Street,
>> Buntingford, SG9 0ED, UK
>> Registered in England and Wales: 3103619
>> 
>> Privacy and Confidentiality Notice:
>> 
>> This is strictly confidential and intended solely for the person or organisation to whom it is addressed. It may contain privileged and confidential information and if you are not an intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this message in error, please notify us as soon as possible and delete it from your system.
> 
>

Received on Monday, 6 July 2015 15:38:21 UTC