Re: GSOC
Hello Greg, Anuj, and Priyesh! Welcome to FreeType :-) We are glad that you are with us the next few months (and maybe even longer), and thank you in advance for the work on your projects. Our main communication is e-mail, which has served us well since the very beginning. Except for really private messages I ask you to always send e-mails to the 'freetype-devel@nongnu.org' mailing list, so please subscribe in case you haven't done so. While you have personal mentors, it is rather that the collective wisdom of this list that will guide you through your work. In particular, you might get an answer earlier because we are distributed all over the world, living in different time zones. We don't have an IRC channel, sorry. Note also that most of us don't have English as our mother tongue, which also means that we are more comfortable with writing e-mails than talking directly. For the former, there is simply more time to formulate words correctly. Don't be shy! You should never hesitate to ask even simple things, if necessary. FreeType is a complex piece of software... Now some technical details. * Please get an account on Savannah https://savannah.nongnu.org/account/register.php and tell me your username so that I can give you write permission for the two FreeType git repositories. * I ask you to put your stuff into a private branch called 'xxx-projectname', with 'xxx' identifying yourself and 'projectname' your preferred project name). If necessary, create more branches to your liking with similar names. * After consolidation of your code (at the end of GSoC) a branch 'GSoC-2020-xxx' should hold the final state of the contribution to which you can refer in your final report. * If you think that your stuff doesn't belong to one of the two FreeType git repositories, feel free to create a repository elsewhere. * Please get used to the (admittedly strange) code formatting rules of FreeType, for which we unfortunately don't have an automatic formatter. Having a uniform appearance of code makes it much simpler to follow the logic. On the other hand, don't worry too much about formatting details; I'll fix minor issues by myself. Of course, this only holds for C (or C++) code that should eventually get merged. * I strongly advise you to learn how to write ChangeLog entries as used in FreeType. This is not necessary for your private stuff, but the final 'GSoC-2020-xxx' branch should follow it. To avoid merging issues, however, I ask you to actually *not* add stuff to the `ChangeLog` file itself. Instead, you should format commit messages as if they were ChangeLog entries. Doing so needs a good amount of self-discipline. Note that I often spend more time in writing a good ChangeLog entry than writing the code, and sometimes I even find problems with my code while doing so :-) As usual, it is more important to document *why* you do the change than describing the change itself – well-written code should tell you that automatically. I also ask you to add comments to the source code for non-trivial things. Werner PS: Anuj and Priyesh, please send your names written in your native scripts :-)
Re: [Freetype-devel] Re: GSOC
Dear Anuj, > Should I call you Suzuki or Sir Suzuki ? Which do you prefer? "Suzuki" is sufficient! Please don't mind about the honorifics, I'm not a native (or good) English user :-). > I have a lot of questions and things to understand about the workflow, so can > I ask them here only or is there a separate mailing list for that ? I guess, other GSoC students might have similar questions in the early phase, so please let's start here. When our discussion is sufficiently specific to the distance fields, let's move to somewhere else. But, if you want to have some non-public e-mail list (and non-public archive?), please let me know. I would try to find something. Regards, mpsuzuki ANUJ VERMA wrote: > Hello, > Should I call you Suzuki or Sir Suzuki ? Which do you prefer? > Thanks for the quick response. > >> So the most stable communication for me is still e-mail, or, the issues & >> discussions in github- (or gitlab- etc) systems. What is your favorite? > > I don't really have a favorite yet, but I do like e-mail and since we are > located in different time zones I think e-mail would be the best option. > I have a lot of questions and things to understand about the workflow, so can > I ask them here only or is there a separate mailing list for that ? > > Thanks, > Anuj > >
Re: [Freetype-devel] Re: GSOC
Hello, Should I call you Suzuki or Sir Suzuki ? Which do you prefer? Thanks for the quick response. > So the most stable communication for me is still e-mail, or, the issues & discussions in github- (or gitlab- etc) systems. What is your favorite? I don't really have a favorite yet, but I do like e-mail and since we are located in different time zones I think e-mail would be the best option. I have a lot of questions and things to understand about the workflow, so can I ask them here only or is there a separate mailing list for that ? Thanks, Anuj
GSOC
Hey, I am glad to know that I got selected for the GSOC. I would like to thank my mentor @Werner LEMBERG and all other community members for their continuous support and guidance. I am very excited to work in FreeType and will need further guidance and support from this group. Thanks again!! Priyesh
Re: [Freetype-devel] Re: GSOC
Hello Anuj! I'm suzuki toshiya, the one of your mentors. I'm glad to have a chance to help your effort of the distance field. I'm really old man who slipped to catch the wave of the recent e-communications like twitter, Slack, Discord etc., and my organization is sometimes filtering the ports for IRC. So the most stable communication for me is still e-mail, or, the issues & discussions in github- (or gitlab- etc) systems. What is your favorite? Regards, mpsuzuki On 2020/05/05 11:48, ANUJ VERMA wrote: Hello all, I received the mail regarding my GSoC 2020 acceptance today and I'd like to thank you all for giving me this opportunity. I also want to thank my mentors Suzuki Toshiya and Alexei Podtelezhnikov. I am really excited to work with you all and integrate distance fields to freetype. I also have the same question as Greg regarding an IRC or Discord channel or any other way in which you communicate. Again, Thank you very much for letting me be a part of the organization. Anuj
Re: GSOC
Hello all, I received the mail regarding my GSoC 2020 acceptance today and I'd like to thank you all for giving me this opportunity. I also want to thank my mentors Suzuki Toshiya and Alexei Podtelezhnikov. I am really excited to work with you all and integrate distance fields to freetype. I also have the same question as Greg regarding an IRC or Discord channel or any other way in which you communicate. Again, Thank you very much for letting me be a part of the organization. Anuj
GSOC
Hi, I like to thank anyone who selected me for a GSoC slot. I look forward to working with you all on implementing a better testing framework over the summer. I realize this mailing list is your primary hub but is there anywhere less formal such as IRC or discord channel where you also associate? Google recommends a bonding period right away so I would like to get to know as much of the team as much as possible :). Look forward to working with you all. - Greg Williamson
Re: Important changes in Docwriter
> This is unfortunate. Is there something less invasive available?
I did a quick search, and came across this pull request in the mkdocs
repository:
https://github.com/mkdocs/mkdocs/pull/1805
I quickly tested this:
* Create the file `docs/markdown/javascript/fetch_shim.js`, adding the
contents of the attached file.
* Run this command in `docs/` directory:
`echo "shim_localSearchIndex = $(cat
reference/search/search_index.json)" >
reference/search/search_index.js`
* Add the two lines below to the `extra_javascript` field in `docs/mkdocs.yml`:
- search/search_index.js
- javascripts/fetch_shim.js
* Run `mkdocs build` in the `docs/` directory.
Search works locally after following these steps.
Unfortunately, this breaks the site (freezes completely because the
script fetch_shim.js goes into some kind of infinite loop) when I try
to serve it locally with `mkdocs serve`.
To implement these changes to allow them to work with docwriter will
require fixing the attached script to prevent the page from freezing,
modifying docwriter to add the required entries to `mkdocs.yml`, and
possibly the build system to create the `search_index.js` file after
the site is generated.
Another option seems to be using the `mkdocs-localsearch` plugin
(https://github.com/wilhelmer/mkdocs-localsearch#installation-material-v4),
but I am getting errors while trying to build the site (with `mkdocs
build`) after following the instructions given in the link.
Unfortunately, it is unlikely that I will be able to find time this
week to work on this, although I can help with finding the files/build
targets to make the required changes once the problems I stated above
are fixed.
Nikhil
// Simple decorator shim for fetch, which makes the search_index.json file
fetchable (ONLY if you enable search:local_search_shim in mkdocs.yml)
fetch_native = fetch
fetch = function(url, options){
// Simple helper to resolve relative url (./search/search_index.json) to
absolute (file://C:/Users...)
var absolutePath = function(href) {
var link = document.createElement("a");
link.href = href;
absolute = link.href;
link.remove();
return absolute;
}
// Check if this fetch call is one we need to "intercept"
if (absolutePath(url).startsWith("file:") &&
absolutePath(url).endsWith("search_index.json")) {
// If we detect that this IS a call trying to fetch the search index,
then...
console.log("LOCAL SEARCH SHIM: Detected search_index fetch attempt!
Using search index shim for " + url)
// Return a "forged" object that mimics a normal fetch call's output
// This looks messy, but it essentially just slips in the search index
wrapped in
// all the formatting that normally results from the fetch() call
return new Promise(
function(resolve, reject){
var shimResponse = {
json: function(){
// This should return the search index
return shim_localSearchIndex;
}
}
resolve( shimResponse )
}
)
}
// In all other cases, behave normally
else {
console.log("LOCAL SEARCH SHIM: Using native fetch code for " + url)
return fetch(url, options);
}
}
Re: Important changes in Docwriter
> I forgot to add that `mkdocs serve` builds the site from the source > markdown files each time, so those too will have to be retained in > the distribution. This is unfortunate. Is there something less invasive available? Werner
Re: Important changes in Docwriter
Hello Nikhil, thanks for your quick response. >> Note that `mkdocs.yml` gets explicitly removed while calling `make >> dist` (see `builds/toplevel.mk`). > > `mkdocs serve` requires the file `mkdocs.yml` to generate the site > and start up the server. Yes, but... > If we want search to be usable locally, I suggest that the file > `mkdocs.yml` be included in the distribution, and `mkdocs serve` be > officially documented as a method to serve the site. Of course, > this will require Python 3 and mkdocs to be available in the > environment. ... the automatically generated `mkdocs.yml` file doesn't work with the tarball because it needs the `markdown` directory, which is intentionally omitted. How to proceed? Can the `mkdocs.yml` file perhaps be adjusted to make searching work? Availability of a local search would be definitely a good thing, and yes, it should also be documented how to get it. Werner
Re: Important changes in Docwriter
I forgot to add that `mkdocs serve` builds the site from the source markdown files each time, so those too will have to be retained in the distribution. Nikhil
Re: Important changes in Docwriter
Hello Werner, > The last step fails with > > Config file '.../docs/mkdocs.yml' does not exist. > > Note that `mkdocs.yml` gets explicitly removed while calling `make > dist` (see `builds/toplevel.mk`). `mkdocs serve` requires the file `mkdocs.yml` to generate the site and start up the server. > What must I do to get local search capabilities? This is, I want to > open the local file > > docs/reference/index.html > > in my browser and be able to use the search field. We had faced a similar issue with local search while initially setting up mkdocs. Searching the list, I found: > Firefox comes with a very strict "file uri origin" policy by default. This > prevents the local page from accessing the file system to get the required > font(s). A workaround is to go to `about:config', filter by fileuri and > toggle the preference > security.fileuri.strict_origin_policy > to set it to `false'. This applies to search too, but is not recommended though, because it may pose security issues. If we want search to be usable locally, I suggest that the file `mkdocs.yml` be included in the distribution, and `mkdocs serve` be officially documented as a method to serve the site. Of course, this will require Python 3 and mkdocs to be available in the environment. Nikhil
Re: freetype2-demos/man/
> Do you mind if we move the man pages from freetype2-demos/src/ to > freetype2-demos/man/? OK. > Can we do it before the release please? Please go ahead! I'm waiting for a response from Nikhil... Werner
freetype2-demos/man/
Hi Werner, Do you mind if we move the man pages from freetype2-demos/src/ to freetype2-demos/man/? This is a common practice and where most people expect to find them. Can we do it before the release please? Thank you, Alexei
