createWorker throws exception with option.langPath set in electron about tesseract.js

[Balearica]

It's unclear to me whether this could break any existing code, so my inclination is to combine this with any other planned breaking changes and release as v6.

[Balearica]

I would agree that the Node.js version should work similarly regardless of whether or not it is being run in Electron, so this condition should be patched if that is not the current behavior.

As an aside, is there a compelling reason to use the Node.js version of Tesseract.js rather than the browser version in an Electron application? My understanding was that Electron supports both, however it was considered a security best practice to avoid giving code access to the filesystem with Node.js integration where possible. However, I have minimal experience with Electron so honestly do not understand the tradeoffs well. The browser version of Tesseract.js can definitely be run using entirely offline resources, as seen in this example repo.

[HQidea]

@Balearica Thx for reply. In Electron, there are two types of processes: main process and render process. As I understand it, what you mentioned and the example you provided is using Tesseract.js in the render process. Upon inspecting the code, I found that the environment is 'webworker' and it utilizes fetch to load language files.

However, in my scenario, I need to run Tesseract.js in the main process after receiving an IPC event from the render process, where the environment is detected as 'electron', and it uses 'node-fetch' to load language files, which does not support local file paths.

[Balearica]

@HQidea Can you make a minimal example repo that can be cloned to replicate this issue? I ran the snippet provided in the OP within the main.js file in the example repo I posted (rather than the index-offline.html file), however everything still ran as expected. Therefore, there is presumably additional context required to replicate this.

[HQidea]

@Balearica this is the repo that can reproduce the error.

I also tried to replicate the error using the repo you provided. However the results are inconsistent. Sometimes the environment in the worker thread is tested as 'electron', and sometimes as 'node'. When the environment is tested as 'node', everything goes well. I'm not sure why.

[Balearica]

@HQidea I was able to reproduce this issue using your repo, and was able to confirm that simply commenting out the special isElectron case within getEnvironment resolved the issue.

tesseract.js/src/utils/getEnvironment.js

Lines 8 to 9 in 83df363

	} else if (isElectron()) {
	env.type = 'electron';

I am hesitant to edit something without fully understanding what it does, so I reviewed the various issues/PRs regarding why a special case for Electron was introduced to begin with. These are linked below.

1. #376 (related commit b8aba2e)
2. #474
3. #489 (related issues #449, #465)
4. #497 (related PR #498)

After reviewing these discussions, I believe Electron was added as a special case because people wanted to use Node.js in an Electron render process. You do not need special logic to use the Node.js version of Tesseract.js in the main Electron process, and you don't need a special logic to use the browser version of Tesseract.js in the render Electron processes. The only "special case" introduced by Electron is the theoretical ability to run Node.js code in what appears to be a browser context (window.document is defined).

While my understanding of Electron is limited, my initial thought is that this special case is not something we need to support. Using Node.js in a renderer process appears to be strongly advised against in the Electron docs. Additionally, the browser version of Tesseract.js works perfectly well in Electron renderer processes, and is just as fast. If this understanding is correct, and there is not a compelling reason to (attempt to) support using the Node.js version in a renderer process, then we could just cut out the Electron-specific stuff entirely, which should solve your issue.

[HQidea]

@Balearica I totally agree with you on not using Node.js in a renderer process.