newfon synthesizer for NVDA

[aleksey_s]

Sergey Shishmintzev who owns russian synthesizer newfon with some help of me has created a special version for NVDA. it is in form of a few dll libraries, so it is pretty portable. without stress dictionary it takes ~400 kb, and rulex dictionary (which is used in espeak for russian language too) is ~2 mb if zipped. Synthesizer can read in russian and Ukrainian after some text preprocessing. bellow is a kind of license for it:

this license is related to a special version of the newfon synthesizer (program), adaptation of which is developed for the NVDA screenreader by Sergey Shishmintzev.
1) permitted to distribute this program with NVDA screenreader or separately, only without financial gains (exclude compensating for the digital media costs).
2) usage of the program allowed only for non commercial purposes.
3) for the commercial purposes usage, or other things which are not described here, please, contact the author of program, Sergey Shishmintzev: sergey.shishmintzev@gmail.com

i have written the NVDA synth driver, which just calls dll and makes some preprocissing (thus not all which is needed). some people allready tested it and said that it is stable. ofcourse synth driver is distributed on gpl license, as all of NVDA source.
also, i want mention, i guess that this synthesizer is needed for russian comunity, becouse it is very much russian-like than espeak russian voice, has good performance, high speed of talking and is portable (not requires installation).

[aleksey_s]

there is some issues when using stress dictionary (it is used only when dict.dll file can be located):
another dll is staticaly linked with dict.dll and somewhat system can not found it (it is located in synthDrivers folder as dict.dll) so i need copy it to system32 folder. i do not know why its happens, staticaly linked dll is in same folder (synthDrivers) with dll it using.

[jteh]

I'm not entirely sure what you are requesting here.

• We could add the NVDA (Python) driver to the main NVDA distribution. However, I'm not sure if there is much point if a customised version of the synth needs to be used anyway. Because the user has to download a version of the synth specific to NVDA, the NVDA driver could be distributed with that version. On the other hand, if the same synth dll is used by other packages, then it makes sense to add the NVDA driver to the main NVDA distribution.
• We cannot distribute the synth itself with NVDA.
  • The biggest reason is that it is seriously incompatible with the NVDA license:
    1. It is not open source.
    2. Perhaps more problematic is the fact that it has restrictions on commercial usage. This is not acceptable for the NVDA project.
  • Also, having different built-in synths for different languages is problematic.
  • It consumes additional space in the distribution. This is a minor issue in this case given its small size.
  • It becomes difficult to manage. Among other things, we would need to implement code to choose a default synthesiser based on the user's language.

I'm certainly open to suggestions as to how we can make this easier for users to integrate with NVDA, but I believe that including it is not an option.

As a matter of interest, what are the problems with eSpeak's Russian support? Would it be possible to fix them?

[aleksey_s]

Replying to jteh:

* We could add the NVDA (Python) driver to the main NVDA distribution. However, I'm not sure if there is much point if a customised version of the synth needs to be used anyway. Because the user has to download a version of the synth specific to NVDA, the NVDA driver could be distributed with that version. On the other hand, if the same synth dll is used by other packages, then it makes sense to add the NVDA driver to the main NVDA distribution.

currently it is used in nvda only (and it is developed especially for it), but i thing putting python module inside nvda repository is quite reasonable becouse it will be easier to track changes: i will add more text preprocessing in it while using this synthesizer, also i planning to add ukrainian support.
i hope you can atleast host it onto nvda site, so russian users can to download it easely. or adding feature to download additional resources into nvda installer will be mutch better solution.

* Also, having different built-in synths for different languages is problematic.

not really problematic i think.

* It becomes difficult to manage. Among other things, we would need to implement code to choose a default synthesiser based on the user's language.

okay, just a few lines of code. dictionary with lang codes and synths. if no key - set espeak. what a problem?

I'm certainly open to suggestions as to how we can make this easier for users to integrate with NVDA, but I believe that including it is not an option.

let's think about nvda resources repository?

As a matter of interest, what are the problems with eSpeak's Russian support? Would it be possible to fix them?

espeak uses english phonems to represent russian ones. so for improving one needs record russian phonems and also make more tweaking which is difficult task.

[jteh]

Replying to aleksey_s:

currently it is used in nvda only (and it is developed especially for it), but i thing putting python module inside nvda repository is quite reasonable becouse it will be easier to track changes

My argument here is that the synth has been customised for NVDA, so no one will use the driver unless they use it with the customised version. Thus, having it in the main NVDA distribution is not useful. See also my similar arguments in #187. Tracking changes is definitely worth considering, but this could be done in another repository.

i hope you can atleast host it onto nvda site, so russian users can to download it easely.

We should be able to organise something for this. I assume the author doesn't have any desire to host the customised version on his/her own site?

* Also, having different built-in synths for different languages is problematic.

not really problematic i think.

It makes sense to use a single synth because it keeps size down and makes for a consistent user experience across languages. However, this argument breaks down given eSpeak's poor support for some languages. :) Ultimately, I'd like to see eSpeak's support for other languages improve, but as you say, this is a very difficult task.

[jteh]

Mick and i have decided to include the Python driver into the main NVDA distribution. If you have updated the driver for current trunk, please attach it here and we will commit it. Thanks.

[aleksey_s]

bzr merge-directive attached

[jteh]

I've only had a chance to take a brief look so far. A few thoughts:

• Was your "main" branch up to date when you generated this merge directive? The preview patch includes a lot of stuff that is already in main. This doesn't matter for the merge itself, but it makes review easier if the patch is clean. You can always generate a merge directive against the real "main" branch.
• nit: check() can just return the result of os.path.isfile(); the if check is redundant.
• Any reason for using global functions and having newfon_lib as a global? It isn't particularly important, though I'm curious, especially as it looks liek they used to be in the class.

[aleksey_s]

Replying to jteh:

* Was your "main" branch up to date when you generated this merge directive?

now i tried to make patch after merging with main - it has 500 kb of size. grr!
so newf one is on old revision.

You can always generate a merge directive against the real "main" branch.

describe, may be i am doing something wrong.

* nit: check() can just return the result of os.path.isfile(); the if check is redundant.

ofcourse. sorry for such a newbie entry :)

* Any reason for using global functions and having newfon_lib as a global? It isn't particularly important, though I'm curious, especially as it looks liek they used to be in the class.

i guess calling global functions is faster than class methods? you need'nt to pass self and mutch more.

[jteh]

Replying to aleksey_s:

now i tried to make patch after merging with main - it has 500 kb of size. grr!

When generating a merge directive:

1. Make sure your copy of main is up to date.
2. If the copy of main you just updated is in ../main, do:

   bzr bundle ../main > bundle_file
   

I just did this and got a bundle file of about 16 kb.

You can always generate a merge directive against the real "main" branch.

This is an alternative to merging with a local copy of main. In this case, you do:

bzr bundle http://bzr.nvaccess.org/bzr/nvda/main > bundle-file

* Any reason for using global functions and having newfon_lib as a global? It isn't particularly important, though I'm curious, especially as it looks liek they used to be in the class.

i guess calling global functions is faster than class methods? you need'nt to pass self and mutch more.

Not much more at all. You already have self, so you don't have to do a lookup for that. Looking up an attribute requires a dictionary lookup for both modules and classes, so the performance is the same for that bit. The performance overhead of using object oriented programming is negligible in this case. (This is not always true.) If we were concerned with performance to this degree, we wouldn't be using Python. :)
Having said that, the functions are utility functions which do not require state, so they could either be global functions or class methods (i.e. using the @classmethod decorator).
newfon_lib is essentially a singleton because you can only load one instance of a library into each process, so having it as a global variable or a variable on the class (not the instance) is probably fine.
It's probably ok to leave these alone for this driver. I just wanted to make the point that we generally prefer an object oriented approach where feasible. Some guidelines:

• global variables and functions are good when they are global to the entire module.
• class (not instance) variables and functions are good when they relate to all instances of a given class. You could use a global, but it makes it easier to follow when variables and functions are located within the scope in which they will be used.
• instance variables and functions are best when they relate to (refer to or act upon) individual instances of a given class.

Of course, there are always cases when these rules should be broken. :)

[aleksey_s]

updated merge-directive. besides other, issue with staticaly linked dlls fixed (looks like hack but works).

[jteh]

I've removed the merge directives, as there is now a newfon bzr branch.

Unfortunately, this cannot be merged into 0.6p3 because the language freeze for 0.6p3 has begun and the driver includes some strings which need to be translated (such as the description of the synth and the available voice names). It can be merged as soon as 0.6p3 is released.

[zvonimir1]

hmmmm this synth needs to be added to test version

[jteh]

Please don't change the ticket information unless you have a particular reason to do so.

The Newfon synth itself will never be added to NVDA because it is not open source and has a restrictive license. See the previous comments for more details.

The NVDA driver for the Newfon synth will be added after 0.6p3. It cannot be added to 0.6p3 due to the language string freeze as noted above.