Issue / Feature request
Is there a way to get Nodebox to export pdf files with the textpaths remaining as editable, non-outlined text?
This would be a very useful feature to have when doing production design work in infographics, because of the need to use opentype features and do copy edits in later design stages when working in Illustrator.
|?||Show this help|
|ESC||Blurs the current field|
|r||Focus the comment reply box|
|^ + ↩||Submit the comment|
You can use
Command ⌘ instead of
Control ^ on Mac
Support Staff 1 Posted by Frederik De Ble... on 04 Feb, 2014 09:39 AM
Sorry for the late answer – your post got lost in the "spam" folder.
This would require an extra "text" node, which we don't have yet.
I've added a GitHub issue that tracks this.
Support Staff 2 Posted by john on 06 Mar, 2017 09:46 AM
Just wanted to echo this request.
In addition to enabling post-Nodebox design flows, text nodes have huge performance advantages in large projects.
The project I'm working on now includes 900 color-coded phrases varying in length from 30 to 130 characters. This is a small part of the overall poster.
Those 900 paths add an additional 3.25 MILLION pointCount and increase the PDF file size by almost an order of magnitude (from 2 megs to 16 megs).
NodeBox can just barely handle this even using my new MacBook Pro. Each time I need to make an adjustment to the phrases I have to wait 60 seconds for the memory overflow error, save the file, quit, and relaunch. This gets old pretty fast.
The resulting PDF file takes an additional 10 seconds to redraw every time you pan or zoom. Everything slows to a crawl.
Text nodes would make my life much nicer. You said you had implemented this for NodeBox Live. Any chance of getting text nodes in NodeBox 3 anytime soon?
Support Staff 3 Posted by Frederik De Ble... on 06 Mar, 2017 10:26 AM
I feel your pain. I think text nodes in NodeBox 3 would be very useful to have.
As you know, we've modeled NodeBox 3 which just one data type for graphics, the vector, which makes it easier for users since all graphical operations work together nicely. However, in NodeBox Live we noticed performance issues with big pieces of text, so we introduced a regular text node there. Of course, not all nodes are compatible with text (e.g. you can't resample a text object). For that there are two solutions:
I found explicit conversions to work better than implicit conversions, therefore that seems the better solution.
However, the bigger issue, as you probably realize, is time. We're gearing up for a NodeBox Live release and don't have much time and/or resources to spend on NodeBox 3. I'll see if I can spend some time on this on my own, but I can't make any promises.
Ideally, we would like to see a single NodeBox 3 / NodeBox Live hybrid version that would perform very well on both desktop and the web, allow integration with the cloud (but also save files locally if you want) and run on many other platforms, including iPads. This is now what I'm spending my time on, as it would be really useful for my own projects as well (eat your own dog food and all that).
We love and would like to support our NB3 community, but we're a very small team, as you know, so we have to be smart where we spend our resources. I still see the two versions coming together, and would love to hear your feedback on this.
4 Posted by rioch on 09 Mar, 2017 01:57 PM
So NodeBox Live is almost here, and having that regular text node makes it more appealing to me. Nice! thanks guys for the hard work. Wonder if there is too much functionality that could not be ported?
But sometimes a browser doesn't feel like the best place to do your work, having gestures enabled for instance can ruin the experience. An hybrid version sounds really cool, or at least have a way to export/import files...
Some game engines use nwjs, could that also work for nodebox?
Support Staff 5 Posted by john on 09 Mar, 2017 11:39 PM
Thanks for your thoughtful response and for requesting my feedback.
Text node and textToPath node with explicit conversion sounds perfect. I would love that.
I will go farther than Rioch: I have no interest whatsoever in creating NodeBox networks inside a web page. The experience just can't compare to developing on a dedicated app. If I can't import my desktop-created networks into NodeBox Live I will have no reason to use it.
What I DO want out of a web/js based NodeBox is the ability to deliver INTERACTIVE visualizations to a wide audience (with no special downloads required). For me this is the holy grail. If I ultimately give up on NodeBox it will because it can't do interactive visualizations.
I use an iPad Pro as my primary computing device (except for NodeBox) and would LOVE to create NodeBox networks directly on my iPad. But not via mobile Safari. I want a real iOS app with all the bells and whistles. In particular, I want to be able to use the Apple Pencil to draw my links. And of course, pinch zoom with my fingers the way god intended.
One final plea. I want the NodeBox UI to stay as simple and clean as the desktop version is now. Although I salivate at having real functions like you do in Nodebox Live, I do not want a permanent function pane - or a documentation pane or any other panes. I want the same simple layout with ouput on the left, network and parameters on the right with everything else accessible through a few icons at the top. I want to start with a clean, blank canvas, not with a typical cluttered IDE dashboad that looks like the control panel for nuclear power plant. I am a UX / UI designer by profession and have a number of other specific ideas to improve the developer experience; let me know if you want to hear any of them.
As always, thanks for listening. I know you guys are swamped so I deeply appreciate everything you do for us.
P.S. That said, could you check your spam folder? Some of my other posts have gone unanswered for over a month now. Thanks.
Support Staff 6 Posted by Frederik De Ble... on 10 Mar, 2017 06:43 PM
Thanks again for the feedback. I know you guys are passionate about the application, and I'm very thankful for that.
Hybrid apps: I've been examining other applications that are purported to be cross-platform, running on mobile devices, and I agree that the experience sucks. They would just claim "oh it's WebGL so it runs everywhere" and then it crashes once you do anything with it. We don't want that. If we do use something like Electron / nw.js, the experience must be seamless, e.g. you won't be able to tell you're using a web application. I believe that could work reasonably well on the desktop, but I don't see this happening on mobile — the performance just isn't there.
Interactive visualizations: that's something we're looking at as well. Specifically, our output target doesn't have to be just the visualization, but a bigger construct, e.g. a HTML page with buttons etc. that interact (and flow back into the app).
UI: There is still a lot of cleanup we can do, e.g. hiding the function pane so you have more working area. I personally like the NodeBox Live runtime model (e.g. functions everywhere), and would -- time pertaining -- love to port it to NodeBox 3.
So what's the plan? Right now, I'm examining porting the NodeBox runtime to C++, then using Emscripten to build this into a library that works on the web (through asm.js or Web Assembly). All supported platforms (Mac/Win/iOS/Web) have a JS runtime, so we would be able to support nodes written in JS on all platforms. Python nodes could be supported on the desktop as well, although other platforms are probably too resource-constrained for this. The built-in nodes could be ported to C++ over time for performance. For the UI, I'd keep the one we made for the web, using Electron, for now. Then, we can examine if this is the right approach or if a fully native approach would work better. I'm a big fan of the IMGUI model for GUI development, which works very well on all platforms.
This whole endeavour is not an easy task: it's something that will require a lot of forethought, work and testing, before we have something that works everywhere. If you'd like to participate to brainstorm on this, please do! We might want to create a new forum thread where we can discuss this further. Also, if you're interested in the future in testing out early builds, that would help a lot as well.