Hallo,
Mijn project is het opbouwen van een gemeenschap gericht op de Tao Te Ching-cultuur. Ik heb meer dan 5.000 oude boeken die ik wil tentoonstellen, en ik heb ze allemaal gecomprimeerd naar het AVIF-afbeeldingsformaat. Sommige van deze boeken bevatten wel 2.500 AVIF-afbeeldingen.
Mijn vraag is: Hoe kan ik deze afbeeldingen in één Discourse-post invoegen om mijn gebruikers ze online te laten lezen?
Ik zoek naar een oplossing, misschien een plugin, die de volgende functies voor gebruikers binnen een post kan bieden:
Gemakkelijk heen en weer bladeren tussen afbeeldingen (zoals pagina’s omslaan).
De mogelijkheid om direct naar een specifiek afbeeldingsnummer te springen.
Cruciaal is dat afbeeldingen ‘lazy-loaded’ moeten worden; ze mogen pas laden wanneer de gebruiker ernaartoe navigeert, niet allemaal tegelijk wanneer de post wordt geopend.
Mijn bestanden zijn allemaal numeriek geordend en in AVIF-formaat. Elk boek bevindt zich in zijn eigen map. De gemiddelde afbeeldingsgrootte is 150 kb en boeken hebben doorgaans tussen de 300 en 1.000 pagina’s, met enkele uitzonderingen die 2.500 pagina’s bereiken.
Waarom heb ik deze vereiste?
Mijn verzameling boeken is enorm, momenteel meer dan 350 GB. Het comprimeren naar AVIF was noodzakelijk om de opslag te beheren.
Formaten zoals AVIF en WebP kunnen niet gemakkelijk in één PDF-bestand worden verpakt.
Het verpakken van de boeken als ZIP- of RAR-archieven verhindert online lezen. Het gebruik van e-boekformaten zoals CBZ zou te veel belasting voor de server veroorzaken.
Heel erg bedankt voor uw hulp!
Hoe grote aantallen AVIF-afbeeldingen in één bericht in te sluiten voor het online lezen van boeken?
Ik zeg dit zelden, maar ik weet niet zeker of Discourse een goed hulpmiddel is voor uw probleem.
Als u het toch wilt proberen, zou ik waarschijnlijk iets doen als een onderwerp per boek maken en misschien een bericht per hoofdstuk, als dat logisch is (misschien zijn er geen hoofdstukken?).
Dan zou je een importscript kunnen gebruiken dat de mapnaam leest en een onderwerp aanmaakt en dan iets doet als
files.each do |f|
u=uploader.create_upload(1, f.path, f.filename)
raw += uploader.html_for_upload(u, f.filename)
end
En dan zou je die ‘raw’ gebruiken om een onderwerp te maken.
Je zou in de map met importscripts moeten kijken om enkele voorbeelden te vinden van het maken van onderwerpen, maar dat is een globaal idee.
En dat zou dan alle afbeeldingen in één onderwerp/bericht plaatsen. En dan zijn er enkele tools waarmee je door een heleboel afbeeldingen kunt scrollen, denk ik. Misschien heeft iemand anders daar meer aandacht aan besteed dan ik.
As was stated, Discourse probably isn’t helpful, at least with hosting your library. Instead, you might want to consider using a separate image hosting service alongside your Discourse instance.
Below is a list of self-hosted photo gallery services that might come with many features that you’d want: out of box web app, user and mobile friendly interface, directory based albums, search capabilities, etc.
You can run the image hosting service separately and use the URLs from it as embedded iframes on Discourse. This would keep your Discourse DB from having to download all the images, and let the image hosting service handle lazy loading. From there, you can start considering using theme components or plugins for standalone pages for the library, auto linking references from user posts, etc.
Ik geloof niet dat dit een kwestie van hosting is, maar van bruikbaarheid bij het lezen. Voor meer westerse, stijlvolle mensen is dit een zeer vergelijkbare vraag als het tonen van strips. En daarvoor kunnen geschikte platforms worden gevonden, maar ik ben er vrij zeker van dat zelfs WordPress een oplossing kan bieden.
En dan is de koppeling van inhoud en community/discussie door Discourse volkomen triviaal.
Maar in het Discourse-ecosysteem zou iets wat Discpage bood, een andere oplossing kunnen zijn. Maar het is kapot.
There are comic file format online reader available, which load files on demand:
GitHub - codedread/kthoom: Comic Book Reader in the Browser for example supports alwaysOptimizedForStreaming=true which tells kthoom to render pages immediately as they are de-compressed and can load from URLs with range requests.
Would that also work if one wants to restrict access to books by user groups or for logged-in users only?
Thank you all so much for your help!
I’ve found a solution: I deployed a Zfile service on my server, which acts as a private cloud drive, and I have configured it to allow anonymous user access.
I can control the number of files displayed per page and customize how many are loaded manually each time. The permissions for anonymous visitors are set to “preview-only.”
This has solved several key challenges for me:
Complex File Management: It’s much more convenient to manage hundreds of thousands of images through a cloud drive interface.
On-Demand Previews: By default, the drive only lists the files, and a preview is generated only when a file is clicked. This works much like PhotoSwipe. (Although Zfile has a mode to preview all images at once, I believe I can disable it later.)
Discourse Integration: I can now add a “Read online” link in my Discourse posts, which opens the cloud drive interface when clicked. It looks like this: 呂祖刪定全書十二卷 - General - Open TTC | 中華傳統道文化知識庫與在綫社區
Resource Efficiency: This approach avoids the unnecessary resource consumption common with traditional galleries or image hosting applications. The best way to read a book is to load one page at a time, unlike a photo album where you expect multiple images at once. Loading multiple book pages simultaneously would also be visually confusing, as every page looks quite similar.
I am using Discourse as my website’s homepage, managing about 5,000 books across 31 categories. Each post represents a single book, and the Zfile drive manages the individual content pages for each one. This is the best user experience I’ve found so far, and it’s relatively convenient on desktops, mobile phones, and tablets. I hope this can help others who might have similar needs.
A couple of notes:
Zfile isn’t the only option. It seems its interface primarily supports Chinese, which is a benefit for me. If you have any better recommendations, please let me know.
If a 3D page-turning plugin (simulating a real book-flipping experience, like those available for WordPress) ever becomes available for Discourse in the future, please let me know as well.
Thanks again!
Your project looks really interesting!
Have you tried wrapping your images in [grid] markdown? A topic like https://openttc.com/t/topic/54 would be much more manageable.
Personally, I have digitized photo albums and saved them in PDF files and uploaded them to topics in Discourse. Then the inline PDF preview theme component lets my members scroll through them directly in Discourse. The advantage with this is that the books stay intact.
Hartelijk dank! Meneer
Recentelijk heb ik aan ontwikkeling gewerkt, waarbij ik tussen meerdere servers heb geschakeld. Daarom kan de openttc.com-link waarnaar in dit bericht wordt verwezen, instabiel zijn.
Zodra ik mijn huidige werk heb afgerond, zal ik een bijgewerkte link in dit topic plaatsen om de resultaten van onze discussie te tonen (het insluiten van Zfile in Discourse-posts, wat nuttig kan zijn voor iemand in de toekomst).
Sterker nog, na lang nadenken heb ik mijn vorige aanpak tijdelijk opgegeven.
De reden is dat het te veel gedoe is om te beheren. Als ik later nieuwe inhoud toevoeg, zou ik deze apart moeten beheren in zowel het Discourse- als het Zfile-systeem en ze handmatig synchroniseren.
Ik probeer momenteel inhoud rechtstreeks in posts in te sluiten als PDF’s. Sommige individuele PDF’s zijn groter dan 2 GB, dus er zijn nog steeds een hoop problemen om langzaam aan op te lossen…
Dank u allen voor uw aandacht. Deze community is echt prachtig!
Ik wens u een goede gezondheid en geluk voor uw families!
Thank you, and same to you and yours! 
I am going to close this topic as it seems you have been able to find some good options for resolving your issue. If you have challenges again in the future you can start new topics.