Indeed it worked. Thank you!
I think there’s an issue with Rack 3.0. See if this change to your Gemfile helps
--- a/Gemfile
+++ b/Gemfile
@@ -1,7 +1,7 @@
source "https://rubygems.org"
gem "sqlite3", "1.4.2"
gem "itextomml", ">=1.6.0"
-gem "rack", ">=2.0"
+gem "rack", "~>2.0"
gem "thin"
gem "after_commit"
gem "rubyzip", '~>2.3.0'
Here we are again… I have just installed Instiki on a machine running Linux Mint Debian Edition 5. Bundling seems OK but when I try to run the program I get this:
Traceback (most recent call last):
6: from ./instiki:6:in `<main>'
5: from ./instiki:6:in `load'
4: from /home/xabier/instiki-0.30.3/script/server:56:in `<top (required)>'
3: from /home/xabier/instiki-0.30.3/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in `require'
2: from /home/xabier/instiki-0.30.3/vendor/rails/activesupport/lib/active_support/dependencies.rb:547:in `new_constants_in'
1: from /home/xabier/instiki-0.30.3/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in `block in require'
/home/xabier/instiki-0.30.3/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in `require': cannot load such file -- rack/handler (LoadError)
7: from ./instiki:6:in `<main>'
6: from ./instiki:6:in `load'
5: from /home/xabier/instiki-0.30.3/script/server:55:in `<top (required)>'
4: from /home/xabier/instiki-0.30.3/script/server:58:in `rescue in <top (required)>'
3: from /home/xabier/instiki-0.30.3/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in `require'
2: from /home/xabier/instiki-0.30.3/vendor/rails/activesupport/lib/active_support/dependencies.rb:547:in `new_constants_in'
1: from /home/xabier/instiki-0.30.3/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in `block in require'
/home/xabier/instiki-0.30.3/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in `require': cannot load such file -- rack/handler (LoadError)
Any help in making some sense of this output? Thanks!
If you’re using the (default) sqlite3 database, that’s a plain file in the db/
directory. Just copy it over to the new installation. If you’ve uploaded files to your wiki, they’re in the webs/
directory. Again, just copy them over to the new installation.
How do I back up and restore a wiki to a new computer? Looking though the instiki site I could not find this …
This may be obvious but I can’t understand how to do it … (I’m an embedded engineer, I can barely spell HTML much less use it)
thx
While there are a few new features, this is primarily a security release, to deal with an issue uncovered by Christian Sattler.
You will need to do a
ruby bundle install
to update some of the dependencies.
Just a tip: you don’t really need to wrap your SVG in a MathML equation. If all you need is to center the figure,
+--{: style='margin: auto; text-align: center'}
<svg> ...</svg>
=--
will suffice (and won’t generate the superfluous MathML wrapper).
(Even better, edit the CSS tweaks for your Web, to add a .centered
class:
.centered {margin: auto; text-align: center}
Then this could be abbreviated to
+--{.centered}
<svg> ...</svg>
=--
)
Ohh. That was a stupid miss on my part. I never thought to look at ids! I changed them and it all works fine now. Thanks a lot
Just so we’re clear, Instiki takes care to uniquify the #id
s of the SVG fragments generated from Tikz source. If you want to generate the SVG yourself, then that responsibility falls on you.
Sorry. I guess I misunderstood what you are doing. Instiki allows the inclusion of Tikz source (either inline or via [!include ...]
). But that’s not what you are doing.
You’ve created two SVG fragments by some means or other. It doesn’t matter whether you put them inline or via [!include...]
. The source of your trouble is that #id
s need to be unique on a page, and your two SVG fragments have duplicate #id
s. Individually, they work fine; but put them on the same page and all hell breaks loose.
Fix your #id
s and you’ll fix your display problems.
This again, has nothing to do with Instiki, its support for Tikz or for SVG. It’s basic X(HT)ML.
I have pages with multiple Tikz-generated images. So I don’t know what your problem is. Perhaps if you porvided a link …
I have a page which includes two SVG images that were generated by tikz and then converted to SVG online. Both of them render perfectly if they are the only images on the page. But when both of them are included, the second image does not render correctly at all. All the math in the image is wrong and includes weird symbols. Is there a fix for this?
Thanks a lot! This works for now. I will ask in Heroku forums in case the timeouts grow inconvenient.
If you’re using the “free” level of service at Heroku, then timeouts can be a problem. It takes a while for Heroku to spin up a Dyno. Just try editing the page again. Once tex2svg is up and running, it should respond very quickly.
As to setup, there are many ways to do it. The simplest is simply to have two Heroku apps that talk to each other over http(s). So, e.g., in Instiki’s config/environments/production.rb
, you could have
ENV['tikz_server'] = 'https://some-name-for-tex2svg.herokuapp.com'
This configuration can suffer from the timeout issue just mentioned.
Better would be to have them both running in the same Heroku instance. But that’s a Heroku question, not an Instiki question and you’ll get better advice on one of the Heroku forums.
I deployed the tex2svg server on Heroku as per the instruction given here by creating a separate app. What exactly do I now need to put in the config/environments/production.rb
file? When I gave the path to the tex2svg Heroku app with port number 9292, it timed out during testing. How do I start the tex2svg server on Heroku? Please guide.
It works now! Thanks!
The problem isn’t on the browser end, but rather on the server end. Instiki is misinterpreting your browsers request for that file (which resides under public/svg-edit/editor/jgraduate/css/jGraduate.css
) with a request for a wiki page (in a web named svg-edit
). That’s not a problem I’m seeing on any of my Instiki installations. So I’m trying to figure out what’s “different” about yours.
Hmm. Looking more closely at your error message, I think this commit might fix your problem. Dunno what the source of the extra space is, but that seems to be the cause of Heroku’s complaints.
I followed the exact instructions on the site. The Gemfile.lock that I can see on my machine also doesn’t have the “BUNDLED WITH” line. The code seems to be running BUNDLED_WITHOUT :
remote: Running: BUNDLE_WITHOUT=‘development:test’ BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 BUNDLE_GLOBAL_PATH_APPENDS_RUBY_SCOPE=1 bundle install -j4
But I do not know what BUNDLED_WITH version it is removing in a previous line. None of the files (Gemfile or Gemfile.lock) seem to have either BUNDLED_WITH or the BUNDLED_WITHOUT line. I found a dicussion on stackoverflow but the accepted answer says the same thing the log file says. I did not run bundle install at any point.
No I do not have any wiki (web) of that name. Or even a page. I got the same error when I tried it with different browsers also (with and without any extensions/addons).
Do you have a Web named “svg-edit”?
Clearly you are trying to use the wrong Gemfile.lock
. The correct one (which you are supposed to rename from Gemfile.lock.heroku
) doesn’t have a “BUNDLED WITH” line in it.
Try following these instructions.
I tried it again and got this error:
—–> Building on the Heroku-20 stack
—–> Determining which buildpack to use for this app
—–> Ruby app detected
—–> Installing bundler 1.17.3
—–> Removing BUNDLED WITH version in the Gemfile.lock
—–> Compiling Ruby/Rack
—–> Using Ruby version: ruby-2.7.1
—–> Installing dependencies using bundler 1.17.3
Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 BUNDLE_GLOBAL_PATH_APPENDS_RUBY_SCOPE=1 bundle install -j4
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
If this is a development machine, remove the /tmp/build_34292e11/Gemfile freeze
by running `bundle install --no-deployment`.
Bundler is unlocking ruby
You have added to the Gemfile:
* rubyzip (~> 2.3.0)
You have deleted from the Gemfile:
* rubyzip (~> 2.3.0)
Bundler Output: You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
If this is a development machine, remove the /tmp/build_34292e11/Gemfile freeze
by running `bundle install --no-deployment`.
Bundler is unlocking ruby
You have added to the Gemfile:
* rubyzip (~> 2.3.0)
You have deleted from the Gemfile:
* rubyzip (~> 2.3.0)
!
! Failed to install gems via Bundler.
!
! Push rejected, failed to compile Ruby app.
! Push failed
I am not sure now if this was a problem from my side.
When I try to add an SVG graphic in a page using the Create SVG button, the popup windows doesn’t display anything. From the log it seems that it is unable find the css file
Processing WikiController#editor (for 127.0.0.1 at 2021-09-25 09:55:03) [GET] Parameters: {“web”=>“svg-edit”, “id”=>“jgraduate/css/jGraduate.css”} Rendering template within layouts/error Filter chain halted as [:connect_to_model] rendered_or_redirected. Completed in 4ms (View: 1, DB: 3) | 404 Not Found [http://localhost/svg-edit/editor/jgraduate/css/jGraduate.css]
Could someone please look into the issue and help?
Hmm. Yes, it looks like the Gemfile.lock.heroku
was out-of-sync with the Gemfile.heroku
. I’ve updated both of them.
I followed the instructions on the instiki site to create and host a wiki on heroku. But there seems to be an error which is probably to do with the gemfile? Here is the build log
—–> Building on the Heroku-20 stack
—–> Determining which buildpack to use for this app
—–> Ruby app detected
—–> Installing bundler 1.17.3
—–> Removing BUNDLED WITH version in the Gemfile.lock
—–> Compiling Ruby/Rack
—–> Using Ruby version: ruby-2.7.1
—–> Installing dependencies using bundler 1.17.3
Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 BUNDLE_GLOBAL_PATH_APPENDS_RUBY_SCOPE=1 bundle install -j4
Fetching gem metadata from https://rubygems.org/...........
Unable to use the platform-specific (x86_64-linux) version of nokogiri (1.11.4) because it has different dependencies from the ruby version. To use the platform-specific version of the gem, run `bundle config set specific_platform true` and install again.
Fetching https://github.com/distler/maruku.git
Fetching rake 12.3.2
Installing rake 12.3.2
Fetching RedCloth 4.3.2
Using bundler 2.1.4
Fetching abstract 1.0.0
Fetching daemons 1.3.1
Installing abstract 1.0.0
Installing daemons 1.3.1
Installing RedCloth 4.3.2 with native extensions
Fetching erubis 2.7.0
Installing erubis 2.7.0
Fetching eventmachine 1.2.7
Installing eventmachine 1.2.7 with native extensions
Fetching file_signature 1.2.0
Installing file_signature 1.2.0
Fetching mime-types-data 3.2018.0812
Installing mime-types-data 3.2018.0812
Fetching multi_xml 0.6.0
Installing multi_xml 0.6.0
Fetching iconv 1.0.8
Installing iconv 1.0.8 with native extensions
Fetching itextomml 1.6.0
Installing itextomml 1.6.0 with native extensions
Fetching json 2.2.0
Installing json 2.2.0 with native extensions
Fetching mini_portile2 2.3.0
Installing mini_portile2 2.3.0
Fetching syntax 1.1.0
Installing syntax 1.1.0
Fetching pg 1.0.0
Installing pg 1.0.0 with native extensions
Fetching rack 2.2.3
Installing rack 2.2.3
Fetching rails_xss 0.4.0
Installing rails_xss 0.4.0
Fetching rdoc 4.3.0
Installing rdoc 4.3.0
Fetching rubyzip 0.9.9
Installing rubyzip 0.9.9
Fetching test-unit 2.5.5
Installing test-unit 2.5.5
Fetching mime-types 3.2.2
Installing mime-types 3.2.2
Fetching nokogiri 1.11.4
Fetching thin 1.7.2
Installing thin 1.7.2 with native extensions
Fetching httparty 0.16.4
Installing httparty 0.16.4
Downloading nokogiri-1.11.4 revealed dependencies not in the API or the lockfile
(racc (~> 1.4), mini_portile2 (~> 2.5.0)).
Either installing with `--full-index` or running `bundle update nokogiri` should
fix the problem.
Bundler Output: Fetching gem metadata from https://rubygems.org/...........
Unable to use the platform-specific (x86_64-linux) version of nokogiri (1.11.4) because it has different dependencies from the ruby version. To use the platform-specific version of the gem, run `bundle config set specific_platform true` and install again.
Fetching https://github.com/distler/maruku.git
Fetching rake 12.3.2
Installing rake 12.3.2
Fetching RedCloth 4.3.2
Using bundler 2.1.4
Fetching abstract 1.0.0
Fetching daemons 1.3.1
Installing abstract 1.0.0
Installing daemons 1.3.1
Installing RedCloth 4.3.2 with native extensions
Fetching erubis 2.7.0
Installing erubis 2.7.0
Fetching eventmachine 1.2.7
Installing eventmachine 1.2.7 with native extensions
Fetching file_signature 1.2.0
Installing file_signature 1.2.0
Fetching mime-types-data 3.2018.0812
Installing mime-types-data 3.2018.0812
Fetching multi_xml 0.6.0
Installing multi_xml 0.6.0
Fetching iconv 1.0.8
Installing iconv 1.0.8 with native extensions
Fetching itextomml 1.6.0
Installing itextomml 1.6.0 with native extensions
Fetching json 2.2.0
Installing json 2.2.0 with native extensions
Fetching mini_portile2 2.3.0
Installing mini_portile2 2.3.0
Fetching syntax 1.1.0
Installing syntax 1.1.0
Fetching pg 1.0.0
Installing pg 1.0.0 with native extensions
Fetching rack 2.2.3
Installing rack 2.2.3
Fetching rails_xss 0.4.0
Installing rails_xss 0.4.0
Fetching rdoc 4.3.0
Installing rdoc 4.3.0
Fetching rubyzip 0.9.9
Installing rubyzip 0.9.9
Fetching test-unit 2.5.5
Installing test-unit 2.5.5
Fetching mime-types 3.2.2
Installing mime-types 3.2.2
Fetching nokogiri 1.11.4
Fetching thin 1.7.2
Installing thin 1.7.2 with native extensions
Fetching httparty 0.16.4
Installing httparty 0.16.4
Downloading nokogiri-1.11.4 revealed dependencies not in the API or the lockfile
(racc (~> 1.4), mini_portile2 (~> 2.5.0)).
Either installing with `--full-index` or running `bundle update nokogiri` should
fix the problem.
!
! Failed to install gems via Bundler.
!
! Push rejected, failed to compile Ruby app.
! Push failed
Could someone help with this issue?
Actually, with tex2svg 1.0.12, the size of the Docker image has shrunk to 1.09 GB.
With the aid of this optional add-on, Instiki (and this forum) can process embedded Tikz code to produce SVG figures. Think of it as a non-WYSIWYG alternative to SVG-Edit. You can get the code from Github.
The easiest way to run it is as a Docker container. The Docker image is 2.14 GB, which is on the large side, but not as large as a full Texlive installation. Instructions for integrating it with Instiki are here.
You will need to upgrade to the latest Instiki if you want to run on Ruby 2.7.
The Instiki website is running on Ruby 2.7.1.