<div dir="ltr"><div dir="ltr"><div><span class="gmail-im"></span></div><div><span class="gmail-im"></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 8, 2019 at 5:24 PM Eli Zaretskii <<a href="mailto:eliz@gnu.org">eliz@gnu.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> From: Ebrahim Byagowi <<a href="mailto:ebraminio@gmail.com" target="_blank">ebraminio@gmail.com</a>><br>
> Date: Fri, 8 Feb 2019 16:02:46 +0330<br>
> Cc: Nathan Willis <<a href="mailto:nwillis@glyphography.com" target="_blank">nwillis@glyphography.com</a>>, Harfbuzz <<a href="mailto:harfbuzz@lists.freedesktop.org" target="_blank">harfbuzz@lists.freedesktop.org</a>><br>
> <br>
> > My conclusion was that ICU is not needed, but maybe it has some advantages,<br>
> <br>
> It will be a good idea if someone ships ICU anyway, they use their ICU (or glib, which can provide unicode<br>
> callbacks also) instead having extra a harfbuzz buildin UCDN, at least for size reduction reasons.<br>
> [...]<br>
> > Glib is needed for running a large part of the test suite<br>
> <br>
> It can provide unicode callbacks also as just said before.<br>
<br>
Thanks, but I still don't think I understand: given that Unicode<br>
character properties are all derived from the same UCD database, what<br>
would be the motivation to use Glib or ICU for these purposes, even if<br>
these libraries are already linked into a program? Do ICU/Glib<br>
support some extensions that UCDN doesn't, or are more likely to<br>
support the latest Unicode Standard?<br></blockquote><div>This is my understanding at least: Binary size reduction, if an application uses ICU already, harfbuzz can use it also, if it uses glib already, harbuzz can use that instead, and if none, harfbuzz can bring its own. Chrome for example uses ICU callbacks so they won't need harfbuzz's ucdn. AFAIK they provide roughly similar quality.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > It is not clear to me what are GObject and Introspection needed for; it would be good to clarify that.<br>
> <br>
> Roughly, gnome way of writing language bindings, ie. make non C/C++ language users able to interact with<br>
> the library with Gnome provided facilities. Not needed for C/C++ or users don't use gobject introspection<br>
> anyway.<br>
<br>
Thanks, this part is now clear, I think.<br>
<br>
> > Btw, the information about "Building on Windows" is IMO outdated:<br>
> > nowadays one can use the "normal" Unix configure/make steps assuming<br>
> > one has MSYS and MinGW installed. That's what I did. There should be<br>
> > no need anymore for any Windows-specific build procedures.<br>
> <br>
> Not everyone will agree with you on that I guess, maybe different use-cases or something, as you see vcpkg<br>
> project <a href="https://github.com/Microsoft/vcpkg/graphs/contributors" rel="noreferrer" target="_blank">https://github.com/Microsoft/vcpkg/graphs/contributors</a> is still a pretty busy project, that's why I<br>
> suggest vcpkg for non-msys Windows users, even instead directly using our cmake on Windows. Vcpkg<br>
> itself uses our cmake but can switch to meson if needed and it can target Linux in addition to Windows, for<br>
> use-cases I am not aware of.<br>
<br>
So maybe that section should be extended to mention both methods?<br>
People who build HarfBuzz on Windows are likely to have MSYS installed<br>
anyway, because building the dependencies mostly does require it. And<br>
even if they don't have it already installed, it's good to mention<br>
that, just so that the reader would know such a method is supported.<br>
When I first read that, I was left wondering whether the normal<br>
configure && make paradigm will get me a port as functional as the<br>
method described on that page.<br>
<br>
Thanks.<br>
</blockquote></div></div>