Re: Removal of plugins and collab from FontForge
[email protected] Mon, 1 Apr 2019 15:20:50 -0700
| Newsgroups | gmane.comp.fonts.fontforge.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============1428765842181404261== Content-Type: multipart/alternative; boundary="------------C23A4C0F92DDCE19AE3FEBBB" Content-Language: en-US This is a multi-part message in MIME format. --------------C23A4C0F92DDCE19AE3FEBBB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On the general issue of parity: there's a big difference between removing the existing functionality and keeping the level of support in both the same. I'm about to add support for genericGlyphChange onto fontforge.glyph. Should I /not/ do this unless and until I implement the equivalent in the scripting language? Wouldn't it be kind of a nightmare to invoke anyway, given the lack of keyword parameters or a hash table? (People have been asking for "Change Glyph" support <https://github.com/fontforge/fontforge/issues/415> for some time, not realizing that it's there at the font level under "genericGlyphChange" because a) the name is weird and b) that function looks like it affects the entire font rather than the selected characters, which is how it actually works. The documentation should have been under "selection interface" the whole time. (Note: I haven't actually tested what's there yet, but if it's broken right now it shouldn't be too hard to get working.)) On this particular issue: I haven't used the native scripting language much. I suppose, given that each scripting file can be thought of as a procedure, you could have a convention for "registering a callback" by passing the name of a file to parse and execute. But it doesn't seem that GW extended his language in this way himself. I don't see why converting the C-language-only encoding plugin facility to a python-language-only facility calls for also supporting it in the other scripting language. Skef On 4/1/19 9:08 AM, Jose Da Silva wrote: > We should try to keep native and python features similar. > The FontAnvil fork happened because someone suggested deleting the native > script tree. > > On April 1, 2019 02:03:08 AM [email protected] wrote: >> Better yet, why not just add the equivalent of AddEncoding to the python >> interface and redo it there? We already have the callback model in >> registerImportExport ... >> >> Skef >> >> On 4/1/19 1:50 AM, T J wrote: >>> As for gb12345, instead of having it as a plugin, we might as well >>> convert it to an in-source compile option, like every other feature >>> that FontForge has. > > _______________________________________________ > fontforge-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fontforge-devel > http://fontforge.10959.n7.nabble.com/Developer-f3.html --------------C23A4C0F92DDCE19AE3FEBBB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p>On the general issue of parity: there's a big difference between removing the existing functionality and keeping the level of support in both the same. I'm about to add support for <tt>genericGlyphChange </tt>onto <tt>fontforge.glyph</tt>. Should I <i>not</i> do this unless and until I implement the equivalent in the scripting language? Wouldn't it be kind of a nightmare to invoke anyway, given the lack of keyword parameters or a hash table?</p> <p>(People have been <a moz-do-not-send="true" href="https://github.com/fontforge/fontforge/issues/415">asking for "Change Glyph" support</a> for some time, not realizing that it's there at the font level under "<tt>genericGlyphChange</tt>" because a) the name is weird and b) that function looks like it affects the entire font rather than the selected characters, which is how it actually works. The documentation should have been under "selection interface" the whole time. (Note: I haven't actually tested what's there yet, but if it's broken right now it shouldn't be too hard to get working.))<br> </p> <p>On this particular issue: I haven't used the native scripting language much. I suppose, given that each scripting file can be thought of as a procedure, you could have a convention for "registering a callback" by passing the name of a file to parse and execute. But it doesn't seem that GW extended his language in this way himself. I don't see why converting the C-language-only encoding plugin facility to a python-language-only facility calls for also supporting it in the other scripting language. <br> </p> <p>Skef<br> </p> <div class="moz-cite-prefix">On 4/1/19 9:08 AM, Jose Da Silva wrote:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <pre class="moz-quote-pre" wrap="">We should try to keep native and python features similar. The FontAnvil fork happened because someone suggested deleting the native script tree. On April 1, 2019 02:03:08 AM <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Better yet, why not just add the equivalent of AddEncoding to the python interface and redo it there? We already have the callback model in registerImportExport ... Skef On 4/1/19 1:50 AM, T J wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">As for gb12345, instead of having it as a plugin, we might as well convert it to an in-source compile option, like every other feature that FontForge has. </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap=""> _______________________________________________ fontforge-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/fontforge-devel">https://lists.sourceforge.net/lists/listinfo/fontforge-devel</a> <a class="moz-txt-link-freetext" href="http://fontforge.10959.n7.nabble.com/Developer-f3.html">http://fontforge.10959.n7.nabble.com/Developer-f3.html</a> </pre> </blockquote> </body> </html> --------------C23A4C0F92DDCE19AE3FEBBB-- --===============1428765842181404261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1428765842181404261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ fontforge-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fontforge-devel http://fontforge.10959.n7.nabble.com/Developer-f3.html --===============1428765842181404261==--