Add LICENSE.md file #1
Comments
|
I will consult with other folks to see what can be adopted as a license here, but the fact that we may have to abide by the ISO policies and Directives could be a necessity. |
|
Generally I am surprised to find licenses on these repos; public Github repos for ISO-related projects should be for discussion only, not contribution. |
|
@dwsinger isn't a MPEG group repo a good place to contribute WG inputs? |
|
ISO doesn't admit the existence of these repos, and any impact on specs would have to be in the form of contributions, written, to the group, or national body comment if the spec. is out for ballot. it's dangerous to have someone lift ideas from a public repo and put them in a contribution document, as this loses traceability. I'm just advising caution; if we get to the point where a conversation suggests a technical contribution, I think we can work it out. I don't think it's a good idea to imply that technical work on ISO specs. can happen here, that's all. |
If you don't make a way for technically minded people to use technically appropriate technology to collaborate on their work then meaningful technical progress is going to be kept to a minimum. |
|
I think that there is a lot that can be achieved through community discussion, and that's fine. Why don't we get to the point where someone wants to make a technical contribution to the ISO spec., and then we can work out the clean way to do it? |
|
@dwsinger I think you are massively underestimating the volume of changes that are incoming. I'll post to the mpeg-otspec list about this now. |
I'm surprised to hear that. Do they admit the existence of the mpeg AHG email lists on an Austrian university server?
The members of the AHG who aren't members of the WG can submit written contributions to the WG via the chair, though, right? I'm failing to see any difference between documents attached to emails sent to the Austrian university listserv, and documents sent to an official mpeggroup GitHub repo via pull request.
GitHub offers a convenient UI to "git blame" which provides line by line, second by second timestamping of contributions to a document for extremely thorough traceability. Attachments to an email seem much less traceable to me.
The current process seems worse. |
See, that's the core of my complaint. That there is no way to contribute to OFF other than getting MS to want to. |
|
@davelab6, @behdad - I find these type of comments disheartening and counterproductive. You both have seen the official list of AHG mandates shared on the AHG email list, you both KNOW that the mandate that establishes the AHG on Font Format prescribes us to use the email list hosted by AAT as our official communication channel (and not just us, all other AHGs established by MPEG Working Groups use the same AAT email lists server) - making comments implying the invalidity or impropriety of officially established AHG communication channel is misleading and ill-advised! And you both do it knowingly, which is troubling, to say the least. |
|
@vlevantovsky Stop communicating with me. |
|
@vlevantovsky I feel like you're stonewalling: on this issue and indeed everything surrounding the OFF process. I spent half my day catching up on the mailing list traffic — partly through emails found in my spam folder and the other part which didn't even get delivered as far as spam though the web archives. The list server is both broken technically and a disaster as far as a venue for collaborative technical development goes. It's no good for what the people with ideas, frustrations, technical skill, motivation, and energy right now want to try to accomplish. Maybe it doesn't bother you personally, but you're not in the same position all the rest of us are. At this point it seems like half the emails are from you saying there are no problems and everything has always gone well and the other half is people trying (and failing) to solve problems you don't acknowledge exist. |
|
@alerque If you look at README, it describes the suggested process on new change proposal that actually took into consideration your comment. However, we also need to satisfy the requirements of the ISO process, where every change in the specification has to have a documented trail that can be tracked: a proposal or a ballot comment > the WG resolution or the disposition of comments > spec change (if accepted). In the past, the proposed changes were always discussed in the AHG and have been submitted to WG either as individual member contributions or as collective AHG contributions, both accompanied by an AHG recommendation to WG to adopt those changes. Strictly speaking, the preliminary discussion of a proposal in the AHG is recommended but not required - any WG member can submit an input contribution to the WG directly. What happens next depends on the WG decision. Since the membership in the AHG is open to general public, we have always considered this to be the community venue by which proposals can be developed and presented to the WG from a diverse group of experts who may not have an opportunity / ability / resources to directly participate in the ISO WG work, but anyone can become a WG member and choose to make direct contributions. |
|
I saw the content of the README. I does not address the substance of my comment. What you're offering:
Vs. what developers these days expect:
|
|
That’s right. And what you’re describing is actually perfectly trackable. Github runs on git, and git offers a Thrn: those accepted changes can be pooled into a “release” (in Github terms), i.e. “proposal” (in ISO terms). Such proposal can be then formatted on a format that is acceptable to the ISO WG (such as .docx if needed, or some other format). Basically that's an equivalent of a compiled software “release candidate”. That “compiled” proposal is turn submitted to the ISO WG for discussion/voting etc. Yes, it’s an ISO process. |
|
@vlevantovsky Quite a few of us understands that ISO requires tracking of changes. It so happens that professional software development also requires that, and is extremely strict about that. Github offers a collaborative system where you can give out permissions, track the changes, preview them in a consolidated fashion. It offers branches that allow different major rewrites of some portions independently of other portions, rather than working on a “live copy” all the time. With Github, you can also perform project management, identify milestones. You can tag issues with different statuses and close them if they are resolved. Finally, there are ways to build “compile” the documents from a source version to a final presentable version, presentation of which can be fine-tuned and controlled, including good typography. Images can be automatically converted from some format to another (for example from SVG to a EMF or PNG that is included in the compiled .docx). There is nothing technical that prevents is from using Github for the AHG work and preparation of deliverables to the ISO WG. On the contrary, this will make the process better. If there is a current mandate that prescribes using some other technical means — what needs to be done so that that mandate is changed? |
|
Yes, this would've been a solution if we had a license to freely edit the source - we don't. I honestly doubt this would ever work - if ISO allows anyone to edit the standard, it would stop being the standard. |
|
Actually, on the contrary :) The pull requests don’t merge themselves, and the projects don’t manage themselves. But perhaps the job might involve less of the boring copy-paste-clean formatting in Word, so that Vlad can actually focus on the merit aspect of the changes (consistency etc.). Working with Github is pleasant, and setting up there necessary software is easy. |
|
WOW. VLAD JUST DELETED MY COMMENT! I had said: "In other words, Vlad will not have a job." |
He's not qualified to. |
|
@behdad You are in direct violation of the ISO Code of Conduct! Disrespectful behavior will not be tolerated. |
|
How is saying that you won't have a job is "disrespectful" in an issue where we are discussing process?! |
Isn't that "backward way" the way the Unicode standard is actually maintained in sync with ISO 10646 ? May be worth checking out the process they have to do that (I don't know, and the unicode FAQ doesn't mention the actual process). |
What do you mean by this? I don't know what you mean by "freely" — we're not proposing a free for all willy-nilly edit process here. What license is the OFF spec document under? Whatever that is could be the answer to this issue: document what the license is and that any snippets, discussions, and PRs here would be released as that (or something compatible) so that there is an open path to inclusion later. Problem solved, and at least we could keep a simple glossary here (see #14) for starters.
Nope, you're the one with the backwards process. It's full of back doors, closed rooms, secret votes, un-editable documents, mailing lists that don't accept attachments, issue trackers that exist but you "don't acknowledge their existence", and other barriers — most non-corporate players don't have a viable path to contribute. Right now our best bet seems to be to get one of the major vendors to adopt our idea and push it through using their back doors.
Again, this suggests you're not listening to the problems the rest of us see in the process. Of course there has to be an approval process and of course it has to include more than a few randos on the internet. But there is better technology to use in collaborating on technical documentation than word docs and mailing list that strips attachments. Any good VCS (it doesn't even have to be GitHub) open to public contribution but with proper curating would do wonders for the standard — both documenting what exists and developing new things. If you don't see the advantages of modern VCS tooling and doubt using them would ever work maybe you're not the best one organize this. |
|
@vlevantovsky it sounds like you are unfamiliar with how github actually works. That's a problem, but it's also something that we can solve and doesn't need to stand in the way of progress. Fundamentally:
It sounds very much like there is a drastic misunderstanding about how git and github work. That can be solved by (1) educating yourself by reading up on how they work (github has really great guides for doing just this on the website), and (2) listening to people when they explain how this system works. Reading through this thread, right now it sounds like the people who should know how git/github works, you included, don't. And that's a problem for literally anyone who wants to help you and the standards body improve the state of affairs. Don't shoot them down, listen to them, and learn from them. Because right now your comments seem to come from a place of misunderstanding about the very nature, capabilities, and process, of the medium that you're posting comments through. |
Nobody except the ISO can “edit the standard”, because the standard is controlled by ISO. The standard is not just some text document. It’s the text document with an ISO “stamp” — and nobody is arguing that we change that. I’m talking about editing the text that will be submitted as a proposal. This is no different than Peter Constable editing the text of the OpenType spec, or people like Behdad writing the text of the COLR proposal, or Sairus Patel writing the text of the CFF2 proposal. They all created and edited a non-normative (from the ISO POV) text, which then was submitted to the AHG, and you incorporated those changes into the ISO working draft. For completely new proposals, this is workable. But for revising the text, retyping large portions of an already existing document in order to reformulate some paragraphs, and then submitting them so that someone (you) again incorporates that into the working draft — that’s actually a very error-prone, tedious procedure. And describing the proposed changes using copyediting methods from the 1940s (“after the second comma in the third sentence, remove ‘or’ and insert ‘and’”) is, IMO, unworthy of developing the cutting-edge technology. Some parties (Adobe, Microsoft) have privileged access to working copies of documents that are often a “search/replace step away” from the ISO standard. (Search for “OpenType”, replace with “OFF”). Other parties do not. |
|
I realize that ISO has a business model and it sells the text of the standards. But let's face it: OFF is not a bestseller. First, the PDF is available free of charge as one of the publicly available standards. Second, most people refer to the MSOT documentation anyway, not the OFF text. There may be some group that buys the ISO OFF anyway, and they'll but it even if the source working drafts are available. Because they pay for the ISO stamp. |
|
Vlad, if the repo isn't official, we can add an Apache license and start collaborating on unofficial documents here? |
No hypothetical "could" about it :) Simon is rewriting it from scratch already, and was told to put it under a standard body so others who are employed by companies with legal departments can allow them to contribute. And Vlad has said he welcomes the effort to write a new edition.
That all happens downstream. It's fine.
If word is used to generate STS XML, we can skip it If not, the current situation persists; we diff the current text with the new one and generate change proposals for the editor to copy and paste into word |
|
I'll be discussing my issues live tomorrow: Those asking for "evidence" can tune in to hear the full allegations first. |
|
@vlevantovsky wrote,
I don't say the email list is invalid or improper. I say it's a technically bad choice, based on technical features and capabilities. I don't say it should be shut down. I say it should be relegated to minor matters, in the same way the w3c font-text community group is prescribing GitHub for majority of matters and their mailing lists for administrivia. I want the AHG to meet the members needs, to be "on par" with alternatives. If this has to happen over a longer time frame, such as waiting for the next time the AHG is re-established, that would be fine. If this really isn't possible, thats fine too. I can live with it. But I'm not sure how many people will be willing to, when there are greener pastures yonder. |
Which will be on October 12. |
Here you go again, you continue to make allegations that someone said something (with someone being me this time around), claiming that I said something, and this is demonstrably not true. If you care to review the email list archive (you can search for "AHG kick-off" messages), you would see that AHG mandates change constantly, depending on the tasks we need to accomplish. What does not change though is our communication channel - there is a value in the continuity of the discussion and in having it open and accessible to all interested parties to join. We did use Yahoo Groups facility for over 15 years, and then switched to another provider when Yahoo Groups discontinued their services. The WG made a choice of another provider this time, choosing the organization who is an active, longtime participant in the work of SC29, and who has a long-standing record of serving the MPEG development community and all AHGs established by MPEG. |
|
@vlevantovsky said,
Great to hear!
Right, which is why splitting it up between this repo and the mailing list is in my opinion not ideal.
GitHub is open and accessible to all interested parties to join.
But the WG can make another choice, each time the AHG is re-established, right? |
|
611bc2f closes this issue. |
|
From the linked declaration document's copyright section:
In other words what I and many others have advocated here is impossible. Quoting @tiroj above (emphasis mine):
As I'm reading the current situation, the ISO does not allow even drafts that people are collaborating on with an eye to eventually proposing to the ISO WG for consideration to be posted publicly. This doesn't just restrict us as a group of would-be contributors from collaborating via Git, it also prohibits us using a Google Doc or anything else with open collaboration. Put another way, the fact cat the AGH mailing list that David & Vlad keep pointing out is open-membership is irrelevant. Quoting @vlevantovsky's Aug 14th email to MPEG-OTSPEC mailing list:
Having the mailing list be open to all subscribers is a useless bit of trivia as long as the list strips attachments and nobody is allowed to post drafts they are working on anywhere else that the list members could collaborate on in a meaningful manner. The existence of the AHG does little to mitigate that the current ISO WG process mandates a closed-doors/back-room/invite-only collaboration process, not just from the WG members themselves but from anybody participating in the process. Bringing in what @davelab6 said above:
This sounds very much like the AHG cannot be reformed. This is born out by Vlad's remarks:
Relevant to the current issue, the established process that we "have to follow" is not just making final proposals in the archaic manor ISO wants to receive them, but the process also mandates that drafts that contributors are working on are not public. That doesn't work for me.
With no personal offense meant, no it hasn't. The last decade or so worth of spec updates are a complete disaster. The quality of the current copy is terrible, an very little technical progress has been made. It is clearly dysfunctional right now in that a large group of people is actively trying to contribute including rewriting copy from scratch and any path to turning that into a contribution is being actively thwarted by "the process that must be followed". The only positive progress has been made by the major vendors updating their respective flavors and those changes getting rubber stamped though, but that still leaves the overall deliverable a total mess that doesn't serve anybody well. @twardoch nailed this above:
This is not the outcome of a working process, it is evidence of a broken process. As discussed above the OFF spec is not usable as a reference guide for implementors, whether shapers or font engineers. The very thing it should be good for it is terrible at. I do not buy the defense that this is the outcome of a process that has worked for 16 years, this is something that has not worked. Back to quoting Vlad:
Nope. It's not. The ISO copyright does not allow drafts to be posted in public, in other words we can't use an open process to collaborate. Issue-only Git repositories are about as useful here as a prototype car in a showroom that has a fancy interior that you can sit in and marvel at all the controls, but there is no engine or transmission and you can only move the car around the showroom by pushing it — i.e. a full scale toy, not a real car. I think we need to actively pursue developing OFF-Next (whatever it ends up being called) under a different umbrella. |
|
@alerque I suspect you totally misunderstood what the draft standard means, and all your conclusions are based on wrong assumptions. Draft standards are produced by ISO Subcommittees and/or their working groups, after the new work item proposal is registered and approved. Anything that happens prior to that (individual proposals, input contribution submitted by members, any supporting documentation to establish new work item are not draft standards - they are simply individual contributions that may or may not be accepted for future standardization. Even when the individual contributions are accepted by the Working Groups, and the working drafts are produced based on these contributions - the working drafts are not considered approved draft standards until the new work item proposal and registration ballot are issued. This is why in the past we could freely distribute and discuss any and all proposals and input contributions in this AHG, and we publicly shared and reviewed working drafts that would then be used to justify creating a new work item. In order to prepare individual proposals and input contributions you can use whatever collaboration tools you like, and collaborate freely with whomever you like. To make a long story short - anything you develop to propose and justify a change to the existing standard or to develop a new standard is NOT considered a draft standard - there are no assurances ever given that it will become a standard. Only after it's been approved and registered as Committee Draft it becomes draft standard. And even then, the committees and their working groups have enough power to decide if they want to make the Committee Draft text available for public review. If Committee Draft is made public, it can be published and shared for review, but it cannot be edited. |
|
@vlevantovsky It's quite possible I've misunderstood the ISO bureaucracy (similarly to how you've misunderstood/misrepresented how VCS tooling works), so thanks for that explanation. However I don't see how the distinction between public contributors working together to draft a proposal (perhaps we could call this phase "scratch space" rather than overloading the term "draft") and formal committee drafts actually helps us much. If the current OFF text isn't something we can post to this or any VCS repo to use as a base for cleanup work –with goal of eventually formally proposing the results of that cleanup work as edits to the spec– then we are still left with nothing to work from and disallowed from using modern tooling. Can we or can we not post the current OFF spec here in a plain text format that could be edited collaboratively until such a point where the changes can be bundled up into a proposal make those edits official? Also you didn't address the other aspects of my concerns. |
I think Vlad has been clear that this isn't his decision at all, but that it is the decision of ISO that the current MOFF text will not be available. But that the current OFF text isn't something we can post to this or any VCS repo to use as a base for cleanup work is acceptable, to me. Being left with nothing to work from is still a workable situation, it "just" means starting from scratch. No small effort, to be sure, but still entirely feasible. It's like being a couch potato and saying you'd love to be able to improve and run a 5k, and then finding out the only event nearby is a marathon; you have to do more exercise to participate, but it's better for you anyway :) We do have a copy of MSOT v1.6, from Adobe, under the Apache license, which was contributed to ISO under the ISO terms, and after actually starting to work with that text, Simon concluded it would be better to start from scratch anyway. I guess that one might reach a similar conclusion even if starting with the 1.8.3 text. Thus, it seems clear to me that we ARE allowed to using modern tooling, and I am grateful that Vlad is willing to translate "iso-ese" for us noobs. There was a similar confusion about the phrase "working group" in July, as I recall. It's clear to me because the current work in the googlefonts colr repo is exactly this modern tooling process! It is just happening 'too far' upstream for my liking, and in a "vendor specific space." I don't think that is ideal. Nor is CommonType currently ideal, being in a "unincorporated collective space." So, the goal of eventually formally proposing the results of the current COLR work as edits to the spec, is equal to the current cleanup work. As long as the process (I try to say protocol, because there is back and forth between various stages/actors) is clearly documented, with a recommend flow, and illustrated with prior best and worse case studies (#12), we can work with it, and iterate on it over time. I think the next step in iterating it is to create an "official" and central space for such work. I'd like to see that be this repo. So, now this repo has licensing terms, let's see if we can add files for discussion to it. I think #14 is a good start. |
I'm not sure it does. I'd like to see something a little bit more liberal. The ISO copyright and data protection policy surely must cover everything we submit so that it can be eligible for an eventual proposal. However it's not clear from my reading of the policy what happens to content that isn't included. Basically, the declaration states that contributors to the process release their submissions to be copyrighted by the ISO. I'm fine with that. But what about submissions that don't make it to that stage? Can we request that contributors to this repository dual-license their contributions and be bound by both the ISO policy and release the contributions under Apache or BSD or Creative Commons or something else? Take the simple example of the glossary submission (#14). If that text ever gets copied into some draft and submitted as a standards proposal I'm totally okay with my contribution being bound by the ISO's declaration. But what if it doesn't? Am I free to use that glossary text on another project? Or only the bits I authored? Could we copy it into CommonType or some other documentation project without running afoul of the licensing? Since non-draft-submission content is not clearly covered by that declaration I think it would behoove those who contribute here in the spirit of open source to both agree to release their contributions for ISO use and also release them to some more generic open license so they could be used in other projects without creating ambiguity. This would cover contributions, code snippets in discussions that are not otherwise called out, etc. This dual licensing could be especially useful in the future if an independent project such as CommonType were leveraged to submit new proposals that get made into new OFF drafts. If it were to be accepted and approved, the status of CommonType (or whatever similar work, it would be more directly in this repo) would change and potentially we could get asked to take it down, putting us right back where we started with a spec we can't edit collaboratively. If our submissions here were dual licensed this kind of catch-22 would be avoided. |
You would, since you own the copyright. But nobody else would, unless you separately licensed it for such usage. I'll further note that even if ISO accepts your submission, you still own the copyright to your submission under their policy, afaict. They claim copyright over the compiled draft/standard, not your submission: you are only licensing it to them for inclusion, not assigning them copyright. I think, unless you want to restrict republication of the materials to ISO, you'll want to dual-license. And doing that up front here is going to be way easier than tracking down all contributors later. |
|
Thank you @fantasai, that was kind of the conclusion I came to as well. The ISO side of things may be taken care of by the current notice, but none of the rest of us or the projects that could be spawned out of an open process are covered at all. I think we need to re-open this issue, and my proposal would be to dual-license so that potential contributors here are free-er to collaborate across projects. Otherwise this is going to be a silo that people on the open-source end of things can't do much more than observe. |
|
If submitting to ISO meant you lose copyright, MS would have lost copyright over OT, but it didn't :) |
|
I haven't had a chance to digest the flurry of mail in this discussion in the past few days, but I see remarks that I think are unduly critical of Vlad.
I do understand the sense of frustration and the seeming opacity of ISO processes. I recall how it seemed to me in 1999 when I wanted to figure out how to make language coding standards truly representative of language diversity: How does one find the secret entrance to that castle? First, Vlad is simply working within the constraints of ISO processes that he doesn't control. He can take inputs from the AHG by whatever means. But he's not free to choose to make the text of OFF available in a public repo for people to proposed edits to. When the AHG—by whatever means—reaches consensus on proposed changes, he can take that to SC29/WG3 as proposed changes for the spec. Or, if the AHG has different ideas for proposed changes but not necessarily a consensus, he can take all of those to WG3. SC29 and WG3 do maintain a complete record or change history. It's just not in the form of merged PRs from a git repo. It take the form of draft editions or amendments at successive stages development, as well as the voting decisions and comments on the drafts from participating SC29 countries. Those are detailed comments: at this line of the standard, here's this problem, make that change; and the decisions on each comment are also recorded. Now, that paper trail isn't in a public repo that anybody can access. The documentation is accessible to those standards bodies that are participating or observing members of SC29. Is that frustrating? Absolutely at times its very frustrating. But it's not Vlad's fault. That's how ISO and IEC have defined their processes. Is there a entry way to get inside the castle? Yes: In whatever country you work or reside, find out who the standards body that engages in work within ISO/IEC JTC1. You can check the current list of SC29 participating and observing members to see if your country is already involved. And check within the company you work at to see if the company is a member of the respective country's standards body. Sometimes there may be a country-internal structure involving multiple standards organizations. For the US, the ISO member organization is listed as ANSI, but activity in committees under ISO/IEC JTC1 is delegated to INCITS, and activity within INCITS related to SC29 is conducted within the INCITS "L3" committee. Now, let me come back to the current processes, that don't provide access to the text, don't provide tools like git repos for proposing changes to the text, and don't provide more access to the documentation trail. At present, that is what it is, and we have to recognize that as part of the price of having OFF as an ISO/IEC standard. But if anybody isn't satisfied with having those obstacles, these are things that can potentially be changed. And the way to do that would, again, start with engaging in your country's standards body, and proposing changes to the ISO Technical Management Board to revise some aspect of processes. Don't expect an easy sell since we're talking about processes used by some 200 countries in hundreds of different committees and subcommittees and coordinated between ISO and other major standards organizations such as IEC.—i.e., any process changes have very broad impacts.
This is unfortunately true, but not insurmountable. For instance, while I was working with SIL International, I was able to figure out how to get engaged with the US committee active in the work of ISO TC37, start attending T37 meetings as a part of the US delegation and get chosen by TC37/SC2 to be the project editor for ISO 639-3. SIL didn't have any special in-roads; in fact, until I started to investigate how to engage, ISO had very much seemed to anybody in SIL I spoke to as a castle with a large moat. I think the biggest advantages corporate players have over non-corporate players are:
I hope this is somewhat helpful. |
@twardoch I think this is somewhat over-stated. First, neither Adobe nor Microsoft have any privileged access to ISO documents other than what any participant in the AHG has had, or that participants in an SC29 national mirror committee can have. (Btw, PKN is an SC29 participating member.) It's true that MS has access to the source for the OT spec. But while the OT spec and OFF are "sync'd" and have very similar content, they are far from identical. (Over the years, the "sync'ing" hasn't been word for word, page by page. And they're structured differently: OT is not linear, while ISO standards are, necessarily, organized linearly. Also, each has sections that are out of scope for the other.) And everybody has access to the publicly-available current edition and amendments to OFF. So, for instance, while I am currently commissioned by Google and MS to work on an update to the OT spec, in order to "sync" changes in OFF as appropriate into the OT spec, my source has been the publicly-available ISO/IEC 14496-22:2019 Amendment 1:2020. And in the past, Vlad has circulated preliminary drafts for a new edition or amendment on the AHG, and I have reviewed those and submitted technical comments via the AHG, just as anybody else in the AHG could do. |
@twardoch What you're overlooking is that you're asking for ISO and IEC to make an exception to processes that are defined to scope to some 200 countries participating in hundreds of technical committees and subcommittees. I don't think that kind of request for a special-case exception can scale in such a large and diverse organization. |
@twardoch I'm certainly willing to acknowledge a lot of quality issues in the OT spec, and derivatively in OFF. But I also think it's fair to say that some significant progress on quality improvement was made in OT 1.8 – 1.8.3, with those improvements making their way into OFF. And I think with input from many people (including you) submitted via the microsoftdocs/typography-issues repo, that the current work will result in further significant quality improvements. |
@alerque I think this is somewhat over-stated. In relation to shaping engines, it's completely true... but that's because shaping engine specs have always been outside the scope of OFF and the OT spec. Should there be some industry-standard specifications for shaping? Absolutely, and that's an area I think should be prioritized. Far more than fighting over the file format spec. But as for the file format spec... Yes, there are gaps in the specification. Some significant ones. For example, ambiguity about the placement of bitmap graphics from the 'sbix' table within a line of text, with the result that three major implementations have three different behaviours (see OT issue 191. Or, as another example, I was just discussing with Ned Holbrook recently the incomplete specification (multiple details) for how nested lookups (e.g., GSUB type 5) are to be processed—all details that the spec should make clear in order to ensure interoperability. Yet, in spite of these kinds of gaps, people have been somehow managing to make font tools, produce fonts, and create (a smaller number of) runtime implementations for the past 20+ years that have a surprisingly high level of interoperability. (And I think it's fair to say far more of the obstacles for font developers have been related to shaping specifications rather than the file format specs.) So, are there parts of the OT and OFF specs that are poorly written and with out of date editorializing? Absolutely. But in practice the majority of those quality issues haven't really impeded the industry anywhere near as much as "not usable" suggests. Would a significant re-write improve quality? Definitely! But the real technical problems in the file format spec that impede interoperability are in details such as the sbix issue above that are not going to get resolved simply by somebody proposing any number of changes or complete re-write of large portions of the text. And those technical issues also are not going to get resolved by looking at one open-source implementation and assuming that can be used as a reference from which the spec should be based. (How many times have I recently heard people say something along the lines of 'That's what comes from having the spec follow an implementation rather than the other way around.') Rather, each of these technical issues requires careful investigation into how specs have been interpreted in different implementations that impact customers broadly, and whether there are reasons to favour one interpretation over others. (E.g., IMO Apple's sbix implementation must be considered the reference, or Google's CBDT implementation the reference, unless there is broad consensus to decide otherwise.) But again, it's my impression that a much bigger hindrance now for font developers is in relation to shaping specifications. Which OFF doesn't attempt to cover beyond the very low level lookup-processing layer. |
So why does OFF not cover shaping, at least to the extent that the OpenType documentation does? Did Microsoft offer the shaping engine documentation to ISO, and ISO rejected it? Or did Microsoft withhold it when offering the font format documentation for standardization? |
|
I'm not aware that ISO ever took an interest. It might also help to understand the early philosophy wrt "Open" in OT/OFF — at least, this is my understanding from reading the spec (I wasn't involved in the late 90s/early 2000s): the OTL formats and feature/lookup model provided a technology platform that different vendors could build their own implementations on. With that perspective, MS's shaping specs were intended to document how to build fonts for various scripts for use on Windows, not as an industry-wide specification. In hindsight, there was certainly a point at which it would have been better to start thinking in terms of the latter, but that's not how they were understood in 2004 when OT 1.4 was submitted to MPEG as the initial basis for OFF. |
What kind of tools can be written by reading the spec alone? Everyone is either using someone else’s code or reverse engineering a dominant implementation (or looking at the code of open source one, if they are lucky). Nothing can be written by reading the spec, not font renderers, not font shapers, not font mappers, not even something as simple as a font sanitizer. |
That is the exact opposite of my experience. Only simple and common things work, everything else is a complete mess. |
We can solve that with better issue tracking. |
It isn't clear what license contributions to this repo are made under, both to the issue tracker, and to the files repository itself.
Here are other MPEGGroup repos with license files:
ISO directive notices
This is impenetrable and I don't like it, but I suppose this is what is most likely to be appropriate.
BSD
This is better, but its rather long... Also, the notices are for "Copyright ISO" but this repo would I guess have "input candidate" files owned by their authors, so I could suggest no notice, and just the license text itself...
MIT
This is recognized by the Github web app (nicely formatted summary at the top) and is what I would recommend (with no notice)
If there are subfolders in this repo where eg a python package is authored, I think it would be fine to have a
LICENSE.mdfile within that folder like this, supplementing the above "ISO directive notices" fileThe text was updated successfully, but these errors were encountered: