joeblackfake1 0 Posted October 5, 2021 Share Posted October 5, 2021 I know this has been discussed multiple times, the 4Mb app size limit make it impossible to support Chinese, Japanese and Korean fonts at the same time. But I just found an article in ROKU partner forum, it describled the possible way to support it: https://partnersuccess.roku.com/hc/en-us/articles/1500005585181-Does-Roku-support-Chinese-Japanese-or-Korean-character-fonts- Issue Supporting non-Latin character fonts in channel Environment CJK fonts SDK Answer Currently, the best way to use Chinese/Japanese/Korean character fonts is by using cachefs or tmp to store the font after dynamically downloading it during runtime. Our documentation on cachefs and tmp can be found in our Developer Docs article, File system. Can someone from Emby team take a look at this solution? See if it can be done. It seems like by inserting a SD card, cachefs can be saved, no need to download everytime. Thanks in advance. Link to comment Share on other sites More sharing options...
speechles 1917 Posted October 5, 2021 Share Posted October 5, 2021 7 hours ago, joeblackfake1 said: I know this has been discussed multiple times, the 4Mb app size limit make it impossible to support Chinese, Japanese and Korean fonts at the same time. But I just found an article in ROKU partner forum, it describled the possible way to support it: https://partnersuccess.roku.com/hc/en-us/articles/1500005585181-Does-Roku-support-Chinese-Japanese-or-Korean-character-fonts- Issue Supporting non-Latin character fonts in channel Environment CJK fonts SDK Answer Currently, the best way to use Chinese/Japanese/Korean character fonts is by using cachefs or tmp to store the font after dynamically downloading it during runtime. Our documentation on cachefs and tmp can be found in our Developer Docs article, File system. Can someone from Emby team take a look at this solution? See if it can be done. It seems like by inserting a SD card, cachefs can be saved, no need to download everytime. Thanks in advance. LOL.. I love when they say that. It is not that easy at all. You have to realize that the current size of the Roku package is 4MB. So it must be downloaded to the only places you can on a roku. TMP or cacheFS. But what they do not say is once the screen saver kicks in it will wipe the cacheFS and you have to fetch again. TMP will exist through the screen saver but it has a max limit of 25MB. The runtime executable and all the variables must fit into TMP too. It will cripple and cramp the application. It might be possible to do this and remove all the other languages except those within CJK. Then it would increase the space available to do this and might be feasible. But it is an endeavor. It isn't something as easy as that sounds. Believe me. Link to comment Share on other sites More sharing options...
joeblackfake1 0 Posted October 6, 2021 Author Share Posted October 6, 2021 Thanks for the detail explanation. I'm not sure the prority of this feature to others. But to me it is one of the highest. This feature has been discussed for years on both Emby and Plex. At least now we have something to try. I'm glad if emby team can put it on the to-do list. In Roku developer docs, it mentioned that "Developers can use the cacheFS: file system to allow applications to cache data to volatile or persistent storage instead of tmp:. End-users can add an external SD card to their device which will preserve the data even after a system reboot and improve performance." Does it mean if we have SD card inserted cacheFS will survive the reboot or screen saver? Link to comment Share on other sites More sharing options...
speechles 1917 Posted October 6, 2021 Share Posted October 6, 2021 (edited) The sheer size of the NotoCJK font is over 25MB. The entire size of cacheFS is 25MB. The font would have to be split into each geography. Chinese, Japanese, Thai, Korean, etc. So that the size of the font would be cut down and allow a running program with runtime space to execute and hold variable references and a screen stack. Read this as it is very involved and you have to juggle components in and out of memory which is something we presently do not do. We would have to manage memory ourselves as the main garbage collection routine would always try to manage cacheFS and remove things. We would have to manage it ourselves to keep the main garbage collection routine from ever fighting with us. It would be very involved. Edited October 6, 2021 by speechles Link to comment Share on other sites More sharing options...
joeblackfake1 0 Posted October 6, 2021 Author Share Posted October 6, 2021 Got it. There will be a lot work to do to make it happen. Then I don't expect it will be done in short time. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now