[HN Gopher] ZetaOffice: LibreOffice in the Browser
___________________________________________________________________
ZetaOffice: LibreOffice in the Browser
Author : marcodiego
Score : 277 points
Date : 2024-11-26 20:32 UTC (1 days ago)
(HTM) web link (zetaoffice.net)
(TXT) w3m dump (zetaoffice.net)
| wmf wrote:
| How does this work? Is it WASM-based or what?
| benatkin wrote:
| It runs on ProseMirror and AG Grid.
|
| Joke aside, the source code isn't featured on the web page,
| despite LibreOffice (unlike Apache OpenOffice) being
| copylefted. They mention self hosting, but it says to contact
| them. It seems it runs on WebAssembly either directly or
| through a VM on top of WebAssembly like https://copy.sh/v86/ .
| The screen seems to be simulated with a canvas. I think perhaps
| they didn't change the code of LibreOffice much, but have a
| custom setup of something like https://copy.sh/v86/ or even are
| running it on actual WebAssembly with a virtual screen. So they
| have a virtual computer that it's running on, and they consider
| that separate when it comes to copyleft obligations. Plus it's
| possible to make something open source but inconvenient, and
| charge to make it convenient.
| hoistbypetard wrote:
| From the description here[1], it sounds like they're using
| WASM builds of LO.
|
| I'm not quite interested enough to spend the CPU cycles it'd
| take to build and see whether that is really the whole story.
|
| [1](https://github.com/allotropia/zetajs?tab=readme-ov-file)
| benatkin wrote:
| That's nice. AFAICT nobody has yet figured out how to run
| the rust compiler in WebAssembly directly, but it runs in
| v86. That's why I wondered if they were taking that
| shortcut for another complex program.
|
| Here's their page about WASM:
| https://wiki.documentfoundation.org/Development/WASM
|
| It says it uses Qt/VCL. Maybe those can talk to canvas in a
| fairly straightforward way, or maybe ZetaOffice chose a
| different backend to get a proof of concept out faster.
| rzzzt wrote:
| Side question: did GTK3's HTML renderer get anywhere? I
| remember a calculator application running in a browser as a
| demo from a long time back.
| thorstenb wrote:
| That still seems to be there, even for gtk4:
| https://docs.gtk.org/gtk4/broadway.html
|
| (but it says, between the lines, mostly stale I guess)
|
| As an aside: one of the very first demos of LibreOffice in
| a browser (from the Collabora people) was using the
| broadway backend. But they've moved on, using their own
| tiled rendering server backend, plus custom, javascript gui
| on the client.
| hoistbypetard wrote:
| It looks like they've developed a javascript library that
| interacts with a WASM build of LibreOffice:
|
| https://github.com/allotropia/zetajs?tab=readme-ov-file
| thorstenb wrote:
| Yup, and it's all fully upstreamed in LibreOffice, see our blog
| (https://blog.allotropia.de/category/libreoffice/), and the
| upstream wiki page:
| https://wiki.documentfoundation.org/Development/WASM
|
| For an even more obvious demo of that, c.f. the hidden gem
| https://zetaoffice.net/demos/simple-examples/rainbow_writer....
| ;)
|
| Current source version powering the demos is
| https://git.libreoffice.org/core/+/0d9eb8245e1a1345ed9526ad8...
| - we should make that more prominent, indeed.
| bigbones wrote:
| It sounds like you might know the answer to this. Would it be
| straightforward to use this for sandboxed headless file
| conversion? You can do that already with LibreOffice, but
| it's a monster amount of unsafe code that's difficult to
| containerize securely
| thorstenb wrote:
| Indeed can be done, proof of concept shown in this talk:
| https://www.youtube.com/watch?v=X8LwaDjcr7M
|
| Regarding sandboxing - everything WebAssembly is heavily
| sandboxed already, and requires cross-origin isolation in
| the browser, so we can use SharedArrayBuffers.
|
| So that's likely no worse than running LibreOffice
| containerized on a server.
| bigbones wrote:
| Oh whoa a 5 minute video for exactly this :) Apologies
| for making you be my Google. Yep, everything in wasm
| makes things much easier to work with, especially if you
| want to run it on a client device
| e1g wrote:
| I just containerized LibreOffice to do docx->pdf
| conversation, but now I'm wondering - what parts seem
| particularly gnarly to you? My naive strategy is to mount
| an external volume to put/collect files, then call
| `soffice` inside the container to process them. We generate
| all source docx files so I'm not worried about an injection
| from that angle.
| karencarits wrote:
| I can remember testing libre office in the browser many years
| ago, seems like that project was frozen in 2020 as others
| external projects emerged. The wiki has a guide for docker:
|
| https://wiki.documentfoundation.org/Development/LibreOffice_...
| gbraad wrote:
| the link you refer to talks about collabora and allotropia. the
| first is what powers Nextcloud Office/Collabora Office online
| and mobile apps (using coolwsd). the latter is allotropia, who
| is behind Zeta that is mentioned here. both have a slightly
| different approach to how this works. as i understand it, all
| of this is upstream and not really frozen; perhaps that page
| needs an update?
|
| Note: "LibreOffice Online is not intended as a standalone
| software. His goal is, instead, to be integrated with other
| tools to edit their documents." ... while Zeta and Collabora
| are standalone.
| chris_wot wrote:
| It wasn't frozen, Collabora were the ones doing the work and
| so they have largely hosted and developed LibreOffice Online.
| gbraad wrote:
| (same thought here; just didn't want to sound harsh)
|
| The idea of LOOL (LibreOffice OnLine) is to be an
| embeddable component; we have used it before on a Moodle
| site. And this is the same for COOL (Collabora Office
| OnLine), which is used by Nextcloud Office (as components
| called COOLWSD, and LOKit).
| FrostKiwi wrote:
| That's excellent! You guys should interact with Nextcloud or
| someone should try their hand at a Nextcloud App [1]. Nextcloud's
| solution to Google Docs & friends is via the integration of
| OnlyOffice[2], which requires a DocumentServer [3] to function in
| the context of Nextcloud. Even without the collaboration aspect,
| having LibreOffice work off WASM, without any extra
| infrastructure requirement would be an excellent edition to that
| ecosystem I think.
|
| [1] https://apps.nextcloud.com/
|
| [2] https://www.onlyoffice.com/
|
| [3] https://github.com/ONLYOFFICE/DocumentServer
| sneak wrote:
| Nextcloud is terrible and will eat your data, silently and
| without remorse. Avoid it at all costs.
| high_priest wrote:
| What does "Nextcloud will eat your data" mean, specifically?
|
| Do you mean the applications of the suit are buggy, or are
| they somehow hackable / leaking private information?
| hobobaggins wrote:
| "Eating your data" seems to refer to very serious bugs
| rather than leaking or vulns.
| aryonoco wrote:
| Nextcloud is a steaming pile of barely maintained donkey dung
| one should not approach with anything other than a 10' pole
| while wearing a full Hazmat suit.
| Jaxan wrote:
| I use it at home just fine. Granted, I only use it for files
| and I'm not using the office apps from it.
| squarefoot wrote:
| What are its cons? I used it years back and worked fine; did
| it transition to the dark side or it's a matter of bugs? I'd
| use it only self hosted of course. Alternatives?
| zaggynl wrote:
| Can you go into what you issues you saw?
| kgeist wrote:
| Last time I checked it (a few years ago), it was quite
| buggy and crashed often for me (self-hosted).
|
| For example, what I remember, there was a module to move
| photos from Google Photos, but it always stopped at 10%
| photos without any errors. Then there was also some
| document suite module and it would hang my entire machine
| regularly, for some reason (had to restart it).
| nathanmcrae wrote:
| I've run Nextcloud for years primarily for webdav file sync
| and calendar+contacts. It pretty much just works. That's not
| to say there isn't any jank, but it's mostly if you try the
| more obscure apps e.g. I've set up the phone track feature
| and it worked for a while, but I've had trouble with it
| recently. Probably fixable, but I just haven't spent the
| time.
|
| I would say it is the core component of my self-(vps)-hosted
| setup and easily the most valuable.
| gbraad wrote:
| how is this different from http://www.collaboraoffice.com/ ?
|
| Collabora works on mobile devices and integrates with Nextcloud
|
| note: they use WASM, so the load is on the client. Collabora
| relies on a server part, though easy to host.
| xrd wrote:
| Zeta.js is such an impressive JavaScript library. I'm blown away.
| The examples where you can load a document in less than ten
| lines, amazing. Then, change colors of all cells in less than ten
| lines, amazing.
|
| I'm also blown away that there is a gulp file in the repository.
| That's a blast from the past.
| chuckadams wrote:
| I'm still working with stuff using grunt (most certainly not my
| choice). gulp is not that bad as a generic task runner, though
| the last thing I'd use it for these days is to build JS
| artifacts.
| starik36 wrote:
| Love the Deep Space 9 Easter egg!
| porphyra wrote:
| While it is an amazing technical feat, there are, expectedly, a
| bunch of quirks to be ironed out. The font rendering, for
| example, is very bad. Very excited to see how this goes in the
| future!
| austin-cheney wrote:
| There is also
| https://fleet.linuxserver.io/image?name=linuxserver/libreoff...
| radeeyate wrote:
| Keep in mind that Zeta office runs completely in the browser
| with WASM while the thing you provided runs on a server and
| just streams back and forth to the client.
| kosolam wrote:
| Looks interesting. What is it?
| AnonC wrote:
| > ZetaOffice is also available as a native Desktop application
| for Linux and Windows. Download the Beta here.
|
| Why is a desktop application being developed and provided if this
| is compatible with LibreOffice (since the latter already has
| desktop applications)? Is it just to have the same name and
| recognition?
|
| Is the desktop application kept on par with the latest
| LibreOffice release or does it only guarantee document format
| compatibility up to a specific version?
| n3storm wrote:
| Looks like anything that can be snapflatpacked will be
| snapflatpacked.
| thorstenb wrote:
| ZetaOffice is focusing on developers wanting to integrate it
| (be that a web app, or a desktop line-of-business application,
| e.g. via Eclipse RCP) - having the exact same code built across
| all platforms should make for excellent consistency (document
| rendering, and API compatibility). We can also offer LTS
| support & security updates, beyond the normal LibreOffice
| 1-year lifetime.
| chrismorgan wrote:
| I just tried the demo on my very capable laptop (ASUS Zephyrus
| G15 2021, Linux, Sway; Firefox, also tried Chromium).
|
| Performance is _execrable_. Text rendering is _awful_. Input is
| simply _broken_ (e.g. my Compose key just doesn't work). Double
| clicking highlighted _the entire canvas thing_ , as well as the
| word under the cursor. Right clicking did nothing. Scrolling
| isn't captured. The first menu thing I happened to try in the
| full-UI https://zetaoffice.net/demos/simple-
| examples/rainbow_writer.... example (Format - Theme, maybe I just
| picked unfortunately) crashed the whole app (which means that it
| just stops working mysteriously, leaving the UI in the last state
| it was in).
|
| And you can't even get started until it's downloaded 50MB.
| (Though I'm actually mildly impressed it's only that size.)
|
| Seriously, this is completely unusable. It's "cool tech demo",
| but I would _hate_ to actually have to use it.
|
| And I'm pretty sure, based on my rather accurate understanding of
| how all these things work (comprehensive on the web side, good on
| the native side, not so much specific about LibreOffice itself),
| that a lot of this is going to be completely unfixable--though a
| couple of the things I identified are fairly straightforward to
| fix, which is if anything a further indictment.
|
| It's going to be extremely hard to get even _decent_ results
| without targeting real DOM instead of going pure-canvas, and you
| _can't_ get excellent results without doing so.
| peutetre wrote:
| > _It's going to be extremely hard to get even decent results
| without targeting real DOM instead of going pure-canvas, and
| you can't get excellent results without doing so._
|
| Sure you can. Google Docs switched to canvas three years ago:
| https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
|
| This wasm application renders to canvas and works fine for me:
| https://bandysc.github.io/AvaloniaVisualBasic6/
|
| This one too: https://flutterweb-wasm.web.app/
|
| Flutter and Google Docs gave up on the DOM because they
| couldn't get it working well enough, consistently enough across
| browsers. When you draw to canvas you get more consistent
| results because you control all the drawing.
| nox101 wrote:
| > Google Docs switched to canvas three years ago:
|
| And broke CJK and emoji input. They only fixed emoji input
| recently. CJK is still broken.
| arcanemachiner wrote:
| > CJK
|
| "The shorthand collective name for the Chinese, Japanese,
| and Korean writing systems."?
| jraph wrote:
| Yep. This is a very widespread acronym, though I can
| understand that it feels like obscure jargon the first
| time you run into it.
| chrismorgan wrote:
| Google Docs isn't pure-canvas: they only switched their
| document area to use it for layout. Text rendering is still
| browser (necessary to keep performance even _close_ ), and
| all the rest of the UI is still DOM. Having thought
| extensively about it, I cannot come up with _any_ advantage
| to the approach they've taken--neither the performance1 nor
| the consistency2 angles make any sense, and the product is
| actively worse because of it3. I've written more about it on
| HN at times, skim https://hn.algolia.com/?query=chrismorgan%2
| 0google%20docs&ty... for more. Seriously, having thought
| about it very carefully and reviewed the matter several times
| over the years, I honestly believe that they _lied_ in their
| justifications.
|
| Flutter... ugh, Flutter on the web is awful awful awful awful
| _awful AWFUL AWFUL_ and I will _hate_ you if you decide with
| open eyes to use it when you're deliberately targeting the
| web.4 I lack energy to express my vitriolic loathing. Just go
| through https://hn.algolia.com/?query=chrismorgan%20flutter&t
| ype=com..., there's lots of detailed explanation of
| specifically what's bad, if you need it.
|
| Avalonia Visual Basic 6? It's the kind of thing where the
| limitations will show least, because of how limited _it_ is.
| And also because it's imitating (not quite the right word,
| but close enough) ancient software which itself wouldn't work
| fully properly if run on current machines. Its text handling
| is dodgy, doesn't do composition properly, scrolling is non-
| native, context menus are non-native which stops some things
| from working properly... but honestly that's kinda the vibe
| they're going for, so it's not particularly upsetting.
|
| Pure-canvas is irredeemably bad. With difficulty you can make
| some things _decent_ even with it, but excellence is
| _impossible_ with _pure_ canvas.
|
| Flutter and Google Docs did _not_ give up on DOM for the
| reasons you cite. Google Docs, I honestly don't understand
| why they gave up on DOM, the reasons they cited publicly
| genuinely don't make sense. Flutter, it was because they
| don't actually care about the web, it's a third-class target,
| and too much of the way they design their API doesn't port to
| DOM directly, so that making DOM a first-class citizen would
| have required compromises in their APIs that they were
| unwilling to make. But it was emphatically _not_ about cross-
| browser consistency.
|
| --***--
|
| 1 Seriously, _Google Docs is slower than it used to be_ ,
| especially with higher latency and jitter.
|
| 2 The parts they replaced had no consistency problems in any
| realistic browsers. Seriously. Their layout requirements are,
| in practice, _really_ basic. The area where consistency can
| _actually_ be a problem is text shaping and rendering, but
| they haven't replaced that since it would tank performance.
|
| 3 My favourite example is keyboard navigation. It doesn't
| match platform conventions, and that's really irritating.
| Since we're in this thread, LibreOffice also flouts platform
| conventions in this area, and it's really irritating.
|
| 4 If you're focusing on mobile and make a mobile app with
| Flutter and also put it on the web with Flutter because why
| not, better than nothing, I won't like you very much, but
| I'll at least _understand_. But if you're saying "we need a
| web thing, how about we use Flutter"... no.
| peutetre wrote:
| > _But if you're saying "we need a web thing, how about we
| use Flutter"... no._
|
| If you're making an application, there's really nothing
| special about the DOM.
|
| You might as well control your drawing. That way you don't
| need to figure out cross browser incompatibilities all day.
|
| And here's what someone who used to work on Google Docs has
| to say about it:
|
| https://news.ycombinator.com/item?id=27133929
| chrismorgan wrote:
| Please look over my comments on HN about Flutter and
| pure-canvas and such. There are big problems. There is
| _plenty_ special about the DOM that you lose and cannot
| gain back if you go pure-canvas. Links. Scrolling. Text
| handling. Composition. And various more.
|
| Use DOM. _Please_ use DOM.
|
| Use canvas for an actual drawing canvas, but for the UI
| and anything else that's largely text, _use DOM_.
| peutetre wrote:
| There aren't "big problems" because it works. When you
| put yourself in the corner of claiming "pure-canvas is
| irredeemably bad" when it's plainly not, then there's
| nothing practical on offer.
| chrismorgan wrote:
| "It works" is a terrible defence, because of the
| different _degrees_ of working.
|
| I'm describing various _specific_ ways in which it
| _doesn't_ work properly, in ways that stop users from
| doing things they may legitimately want to do, or which
| will frustrate some users, and you're just disregarding
| them. I'm not being vague in most of my complaints, I'm
| being _very specific_.
|
| It's like you have a screw, and it's worn enough that
| sometimes it makes the screwdriver slip, but you're
| saying "just be careful, maybe apply a little more
| pressure, and it still works".
| peutetre wrote:
| > _and you're just disregarding them._
|
| Of course. You're living in a world of your own imagined
| requirements. The practical reality is that there are
| plenty of use cases for this stuff, whether you like it
| or not. This stuff is fit for purpose for many purposes.
| wiseowise wrote:
| How the hell you can claim "it works" if you can't even
| select text out of the box, lmao?
| peutetre wrote:
| Because I can select text out of the box.
| wiseowise wrote:
| Okay, this getting absurd. At this point I'm 90%
| convinced that you're just trolling.
|
| https://news.ycombinator.com/item?id=42252999
|
| You can't select text in neither of your provided samples
| on both PC and mobile in different browsers.
| peutetre wrote:
| You can. Text selection works, cut and copy and paste
| works, zooming works.
|
| I don't know what you're doing.
| wiseowise wrote:
| Which browser/OS?
| erinaceousjones wrote:
| What about screen readers and mobile users? There's all
| these useful accessibility tools that would also have to
| be reinvented for canvas based apps.
|
| Text selection and getting it to bring up a keyboard is
| iffy on the canvas-based things you linked to (I'm
| looking at them on Firefox for Android on a Pixel 6).
| Sure, the VB one is a desktop app. But the original (non
| canvas) version of that app likely worked with windows
| screen readers, and that is lost in this reincarnation
| onto the web. Good old fashioned DOM already has pretty
| good native accessibility support for mobile phone UI.
|
| There's a lot of things that have been thought about when
| it comes to usability and accessibility, in both the web,
| and traditional desktop/mobile UI frameworks.
|
| Reimplementing those UI frameworks in canvas in a browser
| environment requires mapping the a11y bits too, not just
| keyboard+mouse input and rendering to screen.
|
| Not to mention Qt and Gtk and the older Android framework
| apps all use forms of markup and styling which are
| inspired by XHTML and CSS and document object
| models......
| wiseowise wrote:
| > Sure you can. Google Docs switched to canvas three years
| ago: https://workspaceupdates.g
|
| You just need to be one of the critical projects for BigTech.
| Easy peasy, compared to <editor_command> index.html.
|
| > This wasm application renders to canvas and works fine for
| me: https://bandysc.github.io/AvaloniaVisualBasic6/
|
| Trying to select text on mobile Safari just selects whole
| canvas. Same for your Flutter example.
|
| What a regression for web. Just so that a couple of
| snowflakes can use their fad of the day or can stay in their
| comfort zone.
| RandomThoughts3 wrote:
| > Just so that a couple of snowflakes can use their fad of
| the day or can stay in their comfort zone.
|
| Or because the DOM is a piece of technology designed for
| rendering documents and not web apps and with limitations
| which has been severely gimping proper rendering of web
| apps for the past decade despite a slew of libraries trying
| to fill the cracks with various amount of success.
| Whichever you prefer.
| eitland wrote:
| Or because Google doesn't like open web technologies,
| standards and interoperability now that they are the king
| of the hill?
| peutetre wrote:
| How are WebAssembly and canvas not open web technologies?
| eitland wrote:
| I didn't say they weren't.
|
| In the case of Google Docs kt might be because it is
| really convenient to use canvas because then it gets much
| harder for clients to do things Google don't like, i.e.
| interoperability.
|
| In other cases, like in IE^h^hChrome and large Google
| products like Calendar and YouTube there have been some
| interesting cases I think.
| homebrewer wrote:
| They're much harder to "disassemble" and applications
| written in them are much harder to modify and a
| relatively open DOM + JS model. Looks like a very
| promising technology for an ad company that's been
| pushing to make ad blockers significantly less effective,
| and has never let you install an adblocker into the most
| popular browser on the most popular platform in the
| world.
| wiseowise wrote:
| Java was made for TV controllers. Now it powers majority
| of enterprise.
|
| JS was made to animate monkey on a screen, and now it
| powers internet.
|
| Technologies start with one goal and evolve.
| jhbadger wrote:
| The fact that there are so many alternative languages for
| the JVM or which transpile to Javascript suggests that
| (at least to many people) that neither were ideal choices
| for their current uses.
| legacynl wrote:
| I think this actually shows the exact opposite.
|
| That is like saying the existence of cargo trucks, pick-
| ups, minivans, campers, and rv's shows that the
| underlying 'internal combustion engine' technology is
| flawed.
|
| I think it rather shows that the technology is so useful
| that it is able to spawn different implementations aimed
| at slightly different use cases.
| troyvit wrote:
| > We build our computer systems the way we build our
| cities: over time, without a plan, on top of ruins.
|
| -- Ellen Ullman
| jancsika wrote:
| My brain compares cities to planned suburban developments
| complete with their wonderful HOAs.
|
| My brain concludes that Ellen thinks we are building our
| computer systems in the least bad way. :)
| solarkraft wrote:
| > Or because the DOM is a piece of technology designed
| for rendering documents and not web apps
|
| IDK, it seems to have been pretty successful at it to me,
| being of the most popular GUI frameworks currently,
| probably _the_ most popular by a wide margin.
|
| Being designed for documents it should exceed at
| rendering documents.
|
| The problem isn't on the DOM itself, it's in mapping
| other frameworks to it. Of course it'd be hard to port
| LibreOffice's rendering to the web, it'd be a crazy
| amount of work to reach parity.
|
| And it's fine to argue that it doesn't make sense at all
| to use the DOM for non-web document editing: OnlyOffice
| doesn't do it either, as far as I'm aware.
|
| It's just a bummer to me since documents are exactly what
| the web was made for.
| CharlieDigital wrote:
| Is `HTMLDivElement` _really_ that different from `class
| Rectangle`?
| RandomThoughts3 wrote:
| Yes, extremely.
|
| A div element is a node in a tree which will be rendered
| by a very opiniated rendering engine adhering to a fairly
| strict set of standards, and which can be manipulated
| using a limited subset of technologies which are
| themselves fairly opinionated.
|
| A class Rectangle can be pretty much whatever you want.
| CharlieDigital wrote:
| > A class Rectangle can be pretty much whatever you want
|
| In what way can an `HTMLDivElement` not emulate a `class
| Rectangle`? - Both are rectilinear
| - Both have width, height - Both can have
| borders, backgrounds - Both can be positioned in
| various grid/layout systems - Both can contain
| child instances - Both can contain a variety of
| child nodes like `Text` - Both can be clipped and
| masked - Both can be layered
|
| What can you do with a `class Rectangle` from a GUI
| perspective that you can't do with an `HTMLDivElement`?
| RandomThoughts3 wrote:
| A class Rectangle can be whatever you want. You can
| overload it. You can change everything including how it's
| rendered. It doesn't have to be any of the things you
| list.
|
| A div element is a node in a tree which will be rendered
| by your browser in the way specified by the spec. You
| absolutely can't freely do most of the actions you list
| to a div. There are severe limitations.
|
| A div doesn't at all emulate a class. Its semantically
| something completely different.
| CharlieDigital wrote:
| > A Rectangle component is a node in a component tree
| which will be rendered by your OS graphics library in the
| way specified by the spec. You absolutely can't freely do
| most of the actions you list to a div. There are severe
| limitations.
|
| No?
|
| It seems like you're just talking about a `Rectangle` in
| the abstract rather than the real limitation that even
| `class Rectangle` is subject to the rules of the runtime
| engine that renders said `Rectangle`...in a component
| tree...with the restrictions of the OS/GUI framework...
| wiseowise wrote:
| So instead of standardized element that works pretty much
| the same on every browser, that can be inspected and
| controlled by virtually every tool that works with web I,
| as a user, get a binary blob, correct?
| peutetre wrote:
| > _Trying to select text on mobile Safari just selects
| whole canvas. Same for your Flutter example._
|
| Ah, so yet again Safari is the problem. The new Internet
| Explorer unfortunately.
| wiseowise wrote:
| It is the same on every browser.
|
| And you can even control zoom/scale on desktop. Very
| accessible!
| wiseowise wrote:
| Can't*
| zelphirkalt wrote:
| Google Docs' Writer (or whatever they call it) is a terrible
| child's toy, just like Word of Office 365. Functionality is
| severely limited compared to traditional word processors like
| LibreOffice.
|
| > Flutter and Google Docs gave up on the DOM because they
| couldn't get it working well enough, consistently enough
| across browsers. When you draw to canvas you get more
| consistent results because you control all the drawing.
|
| And as a side effect, of course if you require the canvas,
| you will also be able to abuse the canvas, to fingerprint
| users. It is strange, how those things seemingly always
| coincide when it comes to Google products.
| peutetre wrote:
| > _Google Docs ' Writer (or whatever they call it) is a
| terrible child's toy_
|
| It's a toy that's making Google a lot of money.
| jfengel wrote:
| For the vast majority of what I do, a toy is all I need.
|
| This is the nasty catch-22. It is preferable to have a
| single tool that handles both simple and complex cases. But
| sometimes, you just can't make one tool that does both
| well. If you optimize for the hard cases, then most users
| will use only a tiny minority of the features.
|
| Microsoft tried to work around that with the "ribbon",
| which tried to learn which features each individual uses.
| Users hated it.
|
| So I keep around LibreOffice for the hard stuff, which I
| write perhaps once a year. And I use Google Docs every day.
| rbanffy wrote:
| > Google Docs' Writer (or whatever they call it) is a
| terrible child's toy, just like Word of Office 365
|
| I'd believe the vast majority of the user base has never
| noticed anything off with these applications. I have
| noticed one or two things missing in the in-browser
| PowerPoint and that's about it. If you want to do precise
| publication layout, Word (and Writer) are not the
| appropriate tools - you'll need something like InDesign.
| otabdeveloper4 wrote:
| > couldn't get it working well enough, consistently enough
| across browsers
|
| Google Docs literally doesn't work in Firefox. (Garbled
| text.)
|
| For Google not working consistently across browsers is a
| feature, not a bug.
| andrekandre wrote:
| interesting, on my 2019 ipad pro, after initial loading that
| took a bit of time, editing was quite quick and fast for me*
|
| i wonder if there is some parts that remain unaccelerated or
| hitting performance bottlenecks on linux/firefox?
|
| * admittedly a bit low-res/ugly and hard to use on touchscreen
| thorstenb wrote:
| Firefox is indeed a bit of a hit-and-miss these days (though
| we absolutely want to support it). Best experience currently
| is on Chrome(ium).
| zelphirkalt wrote:
| Any ideas why it is hit and miss?
|
| Do you test as much on FF as on Chromium based browsers,
| during development, as well as in quality assurance steps?
| I could imagine, that some devs are looking at it in
| Chromium (or even Chrome _shudder_ ) all day, while
| implementing things, and then just having to tick a
| checkbox for FF "Yep, seems to work.". Which would of
| course lead to a Chromium-centric code.
| thorstenb wrote:
| Most devs here use FF as their daily driver - that said,
| if you need to debug an emscripten-compiled c++ WASM
| application in the browser, then it's either printf-
| debugging, or Chrome + the C/C++ DevTools extension.
| Additionally, the overall QoI for running WASM binaries
| appears quite a bit better for Chrome. Both issues tip
| the scales currently, in favour of Chrome (sadly).
| tjoff wrote:
| Barely worse than Teams or your typical web app. Needs polish
| for sure but the bar for web apps aren't exactly high.
|
| Canvas usually breaks text selections etc. and accessibility.
| But what they do seem to perform much better than trying to get
| the DOM to do something it wasn't designed for.
| chrismorgan wrote:
| When you delve into badly-performing web apps, DOM is almost
| never the actual performance bottleneck. It's other things
| they're doing. And in the rare cases where DOM _is_ the
| bottleneck, it's always that they were abusing it.
|
| As for this case, I have _never_ encountered a web app with
| performance (throughput and latency) problems like this. Not
| anywhere _near_ it.
| tjoff wrote:
| Similarly I don't think canvas is the bottleneck here.
|
| Oh, and abuse is the name of the game. Almost exclusively
| the only thing the browser deals with is abuse. Logical
| consequence when the users are the one paying for it.
| zelphirkalt wrote:
| MS Teams is among the worst pieces of software, that people
| have to deal with on a daily basis, because it gets shoved
| down their throat at their jobs. If something is even worse
| than that, even if "barely", then it is a complete disaster.
| A little "polish" will not be able to make it right.
| giamma wrote:
| OnlyOffice has decent performance and is pure canvas. However,
| they have (or had) issues with respect to accessibility, as
| screen readers don't read canvas.
| samiv wrote:
| "Release early, release often", isn't that the often touted
| wisdom?
|
| Of course that has the problem is that you can make the "first
| impression" only once and when that said "first impression" is
| terrible it can be really hard to convince anyone to try the
| software again for the second time.
|
| I guess releasing, almost like everything else, is a balancing
| game between two early or too late and both extremes have
| costs.
| curt15 wrote:
| The UI in the home page screenshot also looks like 90s-era
| Windows.
| exe34 wrote:
| Ooh that's great, I might give it a try.
| rbanffy wrote:
| I miss 1970's 3278 vibes. PROFs ftw!
| yunyu wrote:
| On the flip side, this is extremely fast and works pretty well
| on my M1 Pro Macbook running Chrome. The only downside is that
| it's a little blurry (as it's rendering at 1x pixel scale).
| thorstenb wrote:
| > It's going to be extremely hard to get even decent results
| without targeting real DOM instead of going pure-canvas, and
| you can't get excellent results without doing so.
|
| One of the ZetaOffice (and LibreOffice) hackers here - and I
| have to disagree.
|
| For something like an office suite, the canvas is literally the
| only way to achieve the document layout fidelity that users
| expect. The DOM does not provide enough knobs & dials to get
| all of MSO (and OOo) bug-for-bug layout compatibility onto the
| screen (and it's not even close). Don't take my word for it,
| see e.g. here: https://news.ycombinator.com/item?id=42100660
| (and that only deals with the text layout parts).
| Animats wrote:
| That animated ad is a total turn-off.
|
| I've used LibreOffice/OpenOffice/StarOffice for two decades now.
| It's OK, not great. At least it interoperates with Microsoft
| desktop formats now. Mostly.
| tpoacher wrote:
| LO is contantly updated and improved. The 2 decades observation
| isn't really useful. Would you compare today's MSO experience
| to MSO2000 on Windows Millenium?
|
| I use LO exclusively and it's a joy to use. On the rare
| instances I'm forced to use MSO it feels only marginally better
| than google docs. YMMV
|
| And, strictly speaking, the reason things break sometimes when
| switching from LO to MSO is because _MSO_ is broken: LO follows
| the spec (both .odt and .docx) faithfully, which then breaks
| when MSO relies on undocumented features or outright bugs for
| the end-result (i.e. the "works best on Internet Explorer"
| legacy).
| squarefoot wrote:
| > I use LO exclusively and it's a joy to use.
|
| Same here and at several other people who asked me for
| alternatives over the years. I installed LO (formerly also
| OO) both on Linux and Windows and they became productive
| almost immediately. However when I install it on other people
| PCs I always set the default save formats as
| Word/Excel/Powerpoint 97-2003 so that nobody will complain
| when they send files to other people who presumably will be
| running mostly MS Office.
| mstngl wrote:
| I would love to have something like this in order to provide the
| office features for documents hosted in nextcloud directly. Yes,
| there is Nextcloud Office/Collabora Office but this needs
| separate provider and is not included in hosted Nextcloud (e.g.
| at Hetzner). The ease of OneDrive + MS365 in comparison is quite
| attracting. For my current use (sharing documents in a team of 50
| - non-commercial but somehow professional approach) the latter is
| still the tool of choice. Being able to share a link, which
| allows others to directly edit presentations and spreadsheets in
| a browser (while the files are available in a local file
| structure) is just great.
| cess11 wrote:
| I might do documents in the browser if LyX was ported to WASM and
| performance is good.
| ptman wrote:
| Cryptpad, which includes a bundled copy of onlyoffice, works
| quite nicely.
| akx wrote:
| Neat!
|
| Couple of observations:
|
| - https://zetaoffice.net/demos/simple-examples/rainbow_writer....
| hangs with an `unreachable` in the console if I try Tools ->
| Options.
|
| - Things don't seem to be hiDPI aware, so everything looks a bit
| unfortunate on e.g. my MacBook's retina screen.
| johnisgood wrote:
| May be an unpopular opinion, but: I do not want LibreOffice in my
| browser, my browser is already slow enough as it is for me.
|
| What next? Blender in the browser? OS inside the browser? (Oh
| yeah, we already have that!)
| doubled112 wrote:
| The browser is the OS now. Everything underneath is just a
| hardware abstraction layer.
| johnisgood wrote:
| I really do not want it to be the future. :(
|
| Just because some people use the browser all the time, it
| does not mean that it should be the "OS". It is silly.
| samuelstros wrote:
| What makes you think the browser as OS is silly?
| bigstrat2003 wrote:
| Agreed. Shoving things into the browser is utterly stupid.
| Native apps are just plain better, stop ruining things by
| putting them in the browser please.
| techwizrd wrote:
| I disagree, it's useful to be able to click a document link and
| quickly preview it in your browser. At work, I have native apps
| for Word, Excel, PowerPoint, etc. and I still find myself using
| the browser version for quickly responding to a comment left in
| a document.
|
| It's also useful to be able to quickly send someone a link to
| collaborate on the document without needing them to install
| anything. Installing a separate app may not be possible for
| aging parents, people using shared computers (e.g., library or
| school computer), or organizations with restricted IT systems.
| johnisgood wrote:
| Previews are different from native apps though, and when you
| click on a link to a document, you only have to click "Open"
| to open a native app. How is this an issue? For quick edits I
| can see the appeal, however.
|
| > Installing a separate app may not be possible for aging
| parents, people using shared computers (e.g., library or
| school computer), or organizations with restricted IT systems
|
| This seems like a non-issue, too. If my grandma were to use
| the PC, I would be the one installing programs (or the OS) on
| it, and if I knew she wanted to open and edit documents, I
| would install LibreOffice. It is one of the programs I
| install on my parent's computer. You (or the IT staff) ensure
| tools are available; you install LibreOffice, similarly to
| how you would install a browser to begin with. For example IT
| staff are already responsible for installing and maintaining
| browsers. Adding productivity software to their
| responsibilities is a standard practice in professional
| environments.
|
| Browser-based tools are a complement, not a replacement, and
| the push toward browser dependence should consider the trade-
| offs in performance, user experience and so forth. Using
| browsers for productivity tools may feel more convenient in
| very specific edge cases, but for most users and workplaces,
| the effort involved in installing and using native
| applications is negligible in comparison.
|
| (I remember the old days when I used https://gobby.github.io
| with my friend to edit code together. It is a native program
| for editing documents (incl. code) together. Today you would
| probably use an extension to VS Code unless it supports it
| natively (no clue).)
|
| I am pretty sure there are people on here who would be able
| to explain it better than I do.
| wakeupcall wrote:
| When "quickly" means downloading 242mb of runtime, running it
| slower than native, on top of the document you want to
| preview...
| EvanAnderson wrote:
| Always a good time for "The Birth and Death of Javascript":
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
| greenavocado wrote:
| The font rendering/kearning makes my eyes bleed
| karel-3d wrote:
| Isn't there the Collabora stuff that's actually optimized for
| browser?
|
| (but I haven't been able to actually run it)
| Andrew_nenakhov wrote:
| From what I understand, Collabora basically runs LibreOffice on
| the server side and relays the resulting image to the client.
| This looks like it has similar approach. And I'm sad to say it
| but Collabora is near unusable compared to Google Docs.
|
| Humanity really does need an online self-hosted office suite that
| natively uses OpenDocument format, but I'm afraid that to achieve
| that it'll be easier to start from scratch with browser version
| as a first platform in mind.
| alwayslikethis wrote:
| Maybe Etherpad?
|
| https://etherpad.org/
| homebrewer wrote:
| Collabora office uses a custom web ui for controls, dialogs,
| etc. The document body is rendered by the server and streamed
| in raster tiles over a web socket.
|
| https://sdk.collaboraonline.com/docs/architecture.html
| fguerraz wrote:
| Collabora is perfectly fine, what's your gripe with it?
| Andrew_nenakhov wrote:
| It is not perfectly fine. It is dreadfully slow and nearly
| unusable compared to Google Documents or native LibreOffice.
| velcrovan wrote:
| Perfect, this gives me a great idea for an April 1 company-wide
| announcement next year.
| merb wrote:
| Is it easy to turn it into a read only mode? Just for viewing?
| Basically I looked forward for such a solution for a long time,
| but everything I've seen is either too heavy or nearly impossible
| to scale.
|
| I did not know that it is possible to wasm build lo!
___________________________________________________________________
(page generated 2024-11-27 23:01 UTC)