command line svg export tool?

[jave]

Hello,

Is it possible to make a command line svg export tool using the codebase? If so, do you have any pointers?

My use case is syncing the tuhi data directory to a server, and batch convert the drawings to svg there.

PS thanks for Tuhi, it really makes the device much more useful!

[gnoack]

(Note, I'm not a project member.)

Tuhi dumps its output data in JSON format into ~/.var/app/org.freedesktop.Tuhi/data/tuhi (using the Flatpak version) and ~/.local/share/tuhi otherwise; I wrote my own converter from that JSON format to PNG and animated GIF.

Tuhi developers: Would it be possible to have a slightly more integrated workflow for converters like these, Unix pipe style? cat x.json | ./my-magic-tool > output.png? :)

PS: I'm happy to contribute my renderer tool once it's a bit more finished, but it's written in Go, unlike Tuhi, so can't be easily integrated into the existing codebase.

[whot]

I understand the use-case but it's not something we've got plans for (let alone the ETIME we currently face). The problem is that on a generic basis, the use-case is limiting and doesn't cover a bunch of the requirements we have. If you look at the history and the current code base you'll find that Tuhi is split into a server and client component. We just couldn't quite figure out how to make the server reliable enough without having a GUI that's integrated with it directly.

As @gnoack notes, the json files are in the various directories anyway and the .svg files used for rendering in the GUI are in the XDG_CACHE_DIR (they get wiped often though).

The main question I'd have is: why do you need to sync to a server and then batch convert there instead of just saving the files in Tuhi? Wouldn't it be more efficient to improve the SVG export feature?

I could envision some nominated directory that Tuhi automatically saves SVG files to, that may not be the worst of all features.

[gnoack]

Hmm, how about this scheme:

• Run /usr/libexec/tuhi/tuhi-server in the background.
• Use the tools/kete.py shell from the Tuhi git repo and put it in listen mode for the given device.

If I'm understanding this right, this would allow Tuhi to basically run in "headless" mode, e.g. on a Raspberry Pi; so that the device would sync automatically with the Tuhi server without GUI interaction, and we could script the images to be sent around in the background. Is this mode of operation reasonable in terms of power consumption and stability? (@whot you're mentioning there are reliability issues with a standalone server?)

@jave is this the same what you're also looking for?

[whot]

that was how Tuhi was originally intended, so it will work. There are a number of issues for the general use-case but for what you're planning to do in a very constrained environment it should work. but there's a reason we don't install kete, we only intended it as a debugging CLI, not as a user-facing command.

As a real issue you may face: IIRC there are still some issues when bluez removes the bluetooth device altogether while tuhi is running. You can get around this by just restarting tuhi, but it'll crash.

[jave]

@gnoack I guess it sounds what I had in mind.

I can clarify my usecase a bit.

I have a laptop which is mostly just used as a client to a remote workstation. Since it is not very reliable to remote a bluetooth session(but doable using trickery) I just run tuhi on the client and upload files to the workstation for further processing.

So one idea was to use unison to sync the json files to the workstation, and use a separate tuhi process there to save the files to svg. But I dont really need the json files for anything in my use case other than to convert them to svg, so I thought they could be directly converted with a cli tool.

Perhaps that makes it clearer? I guess using a lightweight laptop and a powerful remote workstation is kind of quirky, so I understand if its not a top priority.

[whot]

For a completely different approach: the JSON files are versioned and there's the theory that if we change it significantly, we'll bump the version (right now they just match the tablet data). So a simple solution without relying on Tuhi would be to just take the .json files and convert them yourself?

If anything, it's likely that this is what you want because tuhi's svg converter is simple but the json files should include things like timestamps etc. that you can then use to replay.

[jave]

@whot that sounds like an interesting idea. Do you have any pointers how I would convert the .json files to svg? For instance, where in the codebase to look?

[whot]

https://github.com/tuhiproject/tuhi/blob/master/DBusInterface.md#json-file-format

the current json to svg conversion is the JsonSvg class in tuhi/export.py

[gnoack]

@jave @whot: I uploaded my JSON-to-PNG/GIF conversion tool at https://github.com/gnoack/tuhirender - I put installation instructions into the Readme file, and from there the rest should be standard unix pipeline plumbing. :) Let me know how it works for you.

Some example images are at https://blog.gnoack.org/post/tuhirender/

[jave]

@gnoack tuhirender does indeed convert tuhi json files to png, thanks!

But I still need the svg files.

atm I'm having problems getting the tuhi gui to work at all, so I even more want a cli tool

the problem I'm having now is that tuhi starts by trying to register a new device, but I dont want to do that, I just want to access the files I have already downloaded.

[jave]

I did a json to svg tool now.
I dont think it need to be more complicated than this. Comments?

#!/bin/env python3
# -*- coding: utf-8 -*-

# JAVE hack to convert tuhi json to svg. Started from
# raw-log-converter.py and then randomly bashed keyboard until it did
# something


import argparse
import os
import sys
import json
import logging

# This tool isn't installed, so we can assume that the tuhi module is always
# in the parent directory
sys.path.insert(0, os.path.dirname(os.path.realpath(__file__)) + '/..')  # noqa
from tuhi.export import JsonSvg

logging.basicConfig(format='%(asctime)s %(levelname)s: %(name)s: %(message)s',
                    level=logging.INFO,
                    datefmt='%H:%M:%S')
logger = logging.getLogger('tuhi')  # set the pseudo-root logger to take advantage of the other loggers


def parse_file(filename, outfilename,   orientation):
    path = filename
    with open(path) as fd:
        json_data = json.load(fd)
    JsonSvg(
        json_data,
        orientation,
        outfilename
    )
    

def main(args=sys.argv):
    long_description = '''
    convert tuhi json to svg
    '''.replace('    ', '')

    parser = argparse.ArgumentParser(description='Converter tool from Tuhi json files to SVG.',
                                     formatter_class=argparse.RawDescriptionHelpFormatter,
                                     epilog=long_description)
    parser.add_argument('filename', help='The json file to load', nargs=1)
    parser.add_argument('outfilename', help='The output file to write', nargs=1)    
    parser.add_argument('--verbose',
                        help='Show some debugging informations',
                        action='store_true',
                        default=False)

    ns = parser.parse_args(args[1:])
    if ns.verbose:
        logger.setLevel(logging.DEBUG)

    parse_file(ns.filename[0], ns.outfilename[0], 'portrait')


if __name__ == '__main__':
    main()

[whot]

the problem I'm having now is that tuhi starts by trying to register a new device, but I dont want to do that, I just want to access the files I have already downloaded.

I think you could get around this by creating a compatible settings.ini file, that should be enough for tuhi to get past the registration point. For a quick reference, here's mine:

cat ~/.local/share/tuhi/DC:2C:26:A0:C9:A8/settings.ini
[Device]
Address = DC:2C:26:A0:C9:A8
UUID = 323b9162760d
Protocol = intuos_pro

I dont think it need to be more complicated than this. Comments?

This would work if it's part of the tuhi repo, but for any "outside" renderer I recommend not relying on the JsonSvg class - it's internal with no public API and can change. My argument above was that since the JSON format itself is (relatively) stable any custom renderer should take that as input and do their own rendering, however they see fit.

[jave]

This works for me now, so this can be closed, unless you want to keep it open.