Re: Removal of plugins and collab from FontForge

--===============3183202926798110062==
Content-Language: en-AU
Content-Type: multipart/alternative;
	boundary="_000_SYAPR01MB304001F92B6AEA41C85EC217C2550SYAPR01MB3040ausp_"

--_000_SYAPR01MB304001F92B6AEA41C85EC217C2550SYAPR01MB3040ausp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Given that it hasn=92t been used at least since 2012 (7 years!), if not mor=
e, I think it=92s fair game to remove. We can=92t keep everything around in=
 the hope that someone will eventually use it.



For Mac and Windows, the point is moot, because we distribute whole bundles=
 all the time.



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.



In terms of fighting =91hotter fires=92 =96 what are you referring to? I=92=
ve been driving a fair chunk of the development recently, and cleaning up t=
his mess has been one of the greatest sticking points to actually making im=
provements.



To give some context, the primary motivation for getting rid of the plugin =
system is because of its dependence of libtdl, and by extension, autotools.=
 I=92ve mentioned this on GitHub, but by moving off autotools, I can do a f=
ull build of FontForge on Windows in under 2 minutes, vs near on an hour un=
der the current build system, with significant speedups on other platforms =
too.



That speed improvement alone is worth its weight in gold, for me having to =
retain my sanity in trying to make changes in any reasonable amount of time=
.



While it=92s clearly possible to change the build system and somehow retain=
 the plugin system, it=92s a waste of time, because I=92m 99% sure no one a=
ctually uses it. Show me one plugin that was written by a third party, and =
I might reconsider.



It=92s a trap to be retaining dead weight features, particularly when we kn=
ow that they aren=92t used, and it certainly isn=92t worth mine or anyone e=
lse=92s time in trying to make changes while having to continually skirt ar=
ound all of this cruft.



Jeremy



________________________________
From: Jose Da Silva <[email protected]>
Sent: Monday, April 1, 2019 11:50:06 AM
To: FontForge developers' discussions
Subject: Re: [fontforge-devel] Removal of plugins and collab from FontForge

On March 31, 2019 02:14:31 AM T J wrote:
> Hi Abraham,
>
> Yep, this should have no effect on the python scripting interface, with
> the exception of removing the loadPlugin and loadPluginDir methods. I
> very much doubt anyone uses these; the only FontForge plugin that I
> know of is gb12345, and that=92s been broken for years.

There were several plugins with 2012 before the conversion from the older
configure to the configure.ac method that got ripped-out. The plugin librar=
y
was mainly more of benefit to binary versions of FontForge, like Windows,
MAC, and Linux distros that disperse binaries in favour of source code.
gb12345 got orphaned in the process.
If you look at the dependencies of 2012 vs the current version, you'll
notice a lower dependency overhead because the optional libraries loaded
lazy method.
There are a couple of issues requesting gb12345, but we've been putting-out
other fires in the meantime, so this has been on the backburner a long time=
.

I looked at making this work at the time I got contrib-extras working, but
I haven't found proper sources to rebuild gb12345 yet, so I didn't make it
work then. In any case it probably may be better mainlining it in the
unicode library instead of hanging as a plugin library. The extra library
was good for when RAM memory was limited with older PCs, but today's PCs
have far more memory that the difference is not significant to keep it as a
loadable library now.
If someone has good sources for gb12345 I'd be interested in mainlining it
in the Unicode library with the other char maps.

My vote would be to leave it there broken until it's fixed, otherwise it ma=
y
get easily forgotten when out-of-sight, out-of-mind.


> Collab was an attempt to allow multiple people to edit the same font at
> the same time. It was introduced a few years back, but unfortunately
> never fully finished. It=92s buggy, unmaintained, and has a reliance on a
> particular version of zeromq (where that version of zeromq is also
> unmaintained).

You may want to ask Dave about this as he sponsored development on it.
Currently we're fighting hotter fires, so this is also another one of them
thing that may sit on the backburner a little while too.
My vote would be to leave it there broken until it's fixed, otherwise it ma=
y
get easily forgotten when out-of-sight, out-of-mind.


_______________________________________________
fontforge-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fontforge-devel
http://fontforge.10959.n7.nabble.com/Developer-f3.html

--_000_SYAPR01MB304001F92B6AEA41C85EC217C2550SYAPR01MB3040ausp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; pad=
ding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<style>
<!--
@font-face
	{font-family:"Cambria Math"}
@font-face
	{font-family:"Yu Gothic"}
@font-face
	{font-family:Calibri}
@font-face
	{}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif}
a:link, span.x_MsoHyperlink
	{color:blue;
	text-decoration:underline}
a:visited, span.x_MsoHyperlinkFollowed
	{color:#954F72;
	text-decoration:underline}
.x_MsoChpDefault
	{}
@page WordSection1
	{margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.x_WordSection1
	{}
-->
</style>
<div lang=3D"EN-AU" link=3D"blue" vlink=3D"#954F72">
<div class=3D"x_WordSection1">
<p class=3D"x_MsoNormal">Given that it hasn=92t been used at <i>least</i> s=
ince 2012 (7 years!), if not more, I think it=92s fair game to remove. We c=
an=92t keep everything around in the hope that someone will eventually use =
it.</p>
<p class=3D"x_MsoNormal">&nbsp;</p>
<p class=3D"x_MsoNormal">For Mac and Windows, the point is moot, because we=
 distribute whole bundles all the time.</p>
<p class=3D"x_MsoNormal">&nbsp;</p>
<p class=3D"x_MsoNormal">As for gb12345, instead of having it as a plugin, =
we might as well convert it to an in-source compile option, like every othe=
r feature that FontForge has.</p>
<p class=3D"x_MsoNormal">&nbsp;</p>
<p class=3D"x_MsoNormal">In terms of fighting =91hotter fires=92 =96 what a=
re you referring to? I=92ve been driving a fair chunk of the development re=
cently, and cleaning up this mess has been one of the greatest sticking poi=
nts to actually making improvements.</p>
<p class=3D"x_MsoNormal">&nbsp;</p>
<p class=3D"x_MsoNormal">To give some context, the primary motivation for g=
etting rid of the plugin system is because of its dependence of libtdl, and=
 by extension, autotools. I=92ve mentioned this on GitHub, but by moving of=
f autotools, I can do a full build of
 FontForge on Windows in under 2 minutes, vs near on an hour under the curr=
ent build system, with significant speedups on other platforms too.</p>
<p class=3D"x_MsoNormal">&nbsp;</p>
<p class=3D"x_MsoNormal">That speed improvement alone is worth its weight i=
n gold, for me having to retain my sanity in trying to make changes in any =
reasonable amount of time.</p>
<p class=3D"x_MsoNormal">&nbsp;</p>
<p class=3D"x_MsoNormal">While it=92s clearly possible to change the build =
system and somehow retain the plugin system, it=92s a waste of time, becaus=
e I=92m 99% sure no one actually uses it. Show me one plugin that was writt=
en by a third party, and I might reconsider.</p>
<p class=3D"x_MsoNormal">&nbsp;</p>
<p class=3D"x_MsoNormal">It=92s a trap to be retaining dead weight features=
, particularly when we
<i>know</i> that they aren=92t used, and it certainly isn=92t worth mine or=
 anyone else=92s time in trying to make changes while having to continually=
 skirt around all of this cruft.</p>
<p class=3D"x_MsoNormal">&nbsp;</p>
<p class=3D"x_MsoNormal">Jeremy</p>
<p class=3D"x_MsoNormal">&nbsp;</p>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" =
color=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Jose Da Silva &lt;d=
[email protected]&gt;<br>
<b>Sent:</b> Monday, April 1, 2019 11:50:06 AM<br>
<b>To:</b> FontForge developers' discussions<br>
<b>Subject:</b> Re: [fontforge-devel] Removal of plugins and collab from Fo=
ntForge</font>
<div>&nbsp;</div>
</div>
</div>
<font size=3D"2"><span style=3D"font-size:11pt;">
<div class=3D"PlainText">On March 31, 2019 02:14:31 AM T J wrote:<br>
&gt; Hi Abraham,<br>
&gt; <br>
&gt; Yep, this should have no effect on the python scripting interface, wit=
h<br>
&gt; the exception of removing the loadPlugin and loadPluginDir methods. I<=
br>
&gt; very much doubt anyone uses these; the only FontForge plugin that I<br=
>
&gt; know of is gb12345, and that=92s been broken for years.<br>
<br>
There were several plugins with 2012 before the conversion from the older <=
br>
configure to the configure.ac method that got ripped-out. The plugin librar=
y <br>
was mainly more of benefit to binary versions of FontForge, like Windows, <=
br>
MAC, and Linux distros that disperse binaries in favour of source code.<br>
gb12345 got orphaned in the process.<br>
If you look at the dependencies of 2012 vs the current version, you'll <br>
notice a lower dependency overhead because the optional libraries loaded <b=
r>
lazy method.<br>
There are a couple of issues requesting gb12345, but we've been putting-out=
 <br>
other fires in the meantime, so this has been on the backburner a long time=
.<br>
<br>
I looked at making this work at the time I got contrib-extras working, but =
<br>
I haven't found proper sources to rebuild gb12345 yet, so I didn't make it =
<br>
work then. In any case it probably may be better mainlining it in the <br>
unicode library instead of hanging as a plugin library. The extra library <=
br>
was good for when RAM memory was limited with older PCs, but today's PCs <b=
r>
have far more memory that the difference is not significant to keep it as a=
 <br>
loadable library now.<br>
If someone has good sources for gb12345 I'd be interested in mainlining it =
<br>
in the Unicode library with the other char maps.<br>
<br>
My vote would be to leave it there broken until it's fixed, otherwise it ma=
y <br>
get easily forgotten when out-of-sight, out-of-mind.<br>
<br>
<br>
&gt; Collab was an attempt to allow multiple people to edit the same font a=
t<br>
&gt; the same time. It was introduced a few years back, but unfortunately<b=
r>
&gt; never fully finished. It=92s buggy, unmaintained, and has a reliance o=
n a<br>
&gt; particular version of zeromq (where that version of zeromq is also<br>
&gt; unmaintained).<br>
<br>
You may want to ask Dave about this as he sponsored development on it.<br>
Currently we're fighting hotter fires, so this is also another one of them =
<br>
thing that may sit on the backburner a little while too.<br>
My vote would be to leave it there broken until it's fixed, otherwise it ma=
y <br>
get easily forgotten when out-of-sight, out-of-mind.<br>
<br>
<br>
_______________________________________________<br>
fontforge-devel mailing list<br>
[email protected]<br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/fontforge-devel">ht=
tps://lists.sourceforge.net/lists/listinfo/fontforge-devel</a><br>
<a href=3D"http://fontforge.10959.n7.nabble.com/Developer-f3.html">http://f=
ontforge.10959.n7.nabble.com/Developer-f3.html</a><br>
</div>
</span></font>
</body>
</html>

--_000_SYAPR01MB304001F92B6AEA41C85EC217C2550SYAPR01MB3040ausp_--


--===============3183202926798110062==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============3183202926798110062==
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

--===============3183202926798110062==--