I am using Apache FOP 1.1 and kalinga.ttf font for Odiya Language(an indian language).
I got following error.
Please do the needful if there is any alternative or solution for this.
As information read from this page,there is scope for Future development of Oriya Language
Till date it is not supporting much oriya lymphs.
1. https://xmlgraphics.apache.org/fop/trunk/complexscripts.html
2. https://issues.apache.org/jira/browse/FOP-2286
Related
There are some variations to documentation for QGIS server 3.22 to 3.28 that I am trying to understand so that I have a better appreciation of the technology stack I am using. I am not experienced with QGIS server nor apache nor fast cgi.
I have just completed an installation of QGIS server 3.28 on Ubuntu 22.04 following exactly these steps as outlined in the QGIS documentation: https://qgis.org/en/site/forusers/alldownloads.html#linux and https://docs.qgis.org/3.28/en/docs/server_manual/getting_started.html#httpserver
This URL works as stated:
http://qgis.demo/cgi-bin/qgis_mapserv.fcgi?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities
In the 3.22 documentation, found here:
https://docs.qgis.org/3.22/en/docs/server_manual/getting_started.html#installation-on-debian-based-systems
it indicates that this query will work, however, I get a 404:
http://qgis.demo/qgisserver?
MAP=/home/qgis/projects/world.qgs&
LAYERS=countries&
SERVICE=WMS&
VERSION=1.3.0&
REQUEST=GetMap&
CRS=EPSG:4326&
WIDTH=400&
HEIGHT=200&
BBOX=-90,-180,90,180
When I substitute /cgi-bin/qgis_mapserv.fcgi? for /qgisserver? the query works as it is supposed to. I than noted that in the 3.22 training documentation here: https://docs.qgis.org/3.22/en/docs/training_manual/qgis_server/wms.html
it never uses the qgisserver? URL variant.
So, is this just a mistake in QGIS documentation or is there a deeper reason for this difference? Thank you.
I recently upgraded hibernate search from version 5.x to version 6.x, and encountered some problems. Most grammars can be processed by referring to the document, but there is a like grammar that cannot be processed directly. The official document also gives a description, However, the content of the document is not detailed enough and cannot be completed.
This is my syntax for 5.x version queryBuilder.moreLikeThis().comparingFields("name").toEntity(product).createQuery()
But I want to use the 6.x version and I don't know how to transform it for the time being
Hope someone who knows can answer, thanks!
As explained in the migration guide, the moreLikeThis predicate doesn't exist anymore in Hibernate Search 6.
But if it's just about a single field, you didn't really need the moreLikeThis predicate to begin with.
This should return the same results as your current code:
SearchSession session = Search.session(entityManager);
List<Product> hits = session.search(Product.class)
.where(f -> f.match().field("name").matching(product.getName()))
.fetchHits(20);
I have created a POC program to exercise the JCR version handling with ModeShape on both 4.0.0.Alph4 and 3.8.0.Final. The version number is increased from 1.0, 1.1, 1.2 1.3, 1.4, and etc. Then I restored the version 1.2 and made changes to it. But I noticed that the new version number is 1.3.0 now. Should the new version number be 1.2.0 (since it is based on the original 1.2) or am I missing something from the program? Thanks!
I would have expected 1.2.1, so it looks like it might be a bug. Please report the issue in the project's bug tracker. ModeShape is an open source project, we'll likely look at the issue much more quickly if you provide a simple test case.
But what we really love is a pull-request that adds to a test class one or more test methods that replicates the problem. We can get that pull-request, run the tests (which would fail), and then fix the problem. This really saves us a lot of time, and it us know that we're fixing the exact problem you see. And you'll know that the fix will be included in the next release.
I'm wondering if there is a way to get data in specific language when using gracenote series_search or series_fetch methods.
It turns out that using ger field is useless... I still get data in english ...
If someone could help resolving this, that would be great! =)
Gracenote uses 3-letter ISO 639-2 codes to specify languages. The format is described at http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes - Gracenote supports most major languages.
Thanks to your suggestion, we've added this documentation to our page at: https://developer.gracenote.com/eyeq
Recently (about a month ago) I was trying to introduce new constructs to my company's in-house extension language, and struggling with a couple of reduce-reduce errors. While I eventually solved this problem, digging into the y.output file was no picnic.
As an experiment, I tried using Bison's --graph=<file> option to output a DOT file (note that our standard build uses Byacc, not Bison). As I'm on a 'turnkey' Linux box, I didn't have a Graphviz installation and could not easily install from RPMs (working on Red Hat Enterprise Linux 4). Instead, I built it from source.
As an initial experiment, I tried to run dotty with an output of Postscript. Now our internal language is your average home-grown, Turing-complete, dynamically typed scripting language, but I was unprepared for what followed. The dotty run took over four hours (2GHz dual core AMD64 box)! And when it was done, the graph that was rendered was not what I would call readable.
So, quite simply, I'm looking for advice. Are there a set of switches which would improve the outcome over the 'default' approach I took? I'm looking for experience in
optimizing 'render' time
improving readability of the graph
possible advice on better graphical viewers
I imagine you've already seen this link, but just for completeness, there is a list of viewers etc. at: http://graphviz.org/resources/ or see https://web.archive.org/web/20131005020548/http://graphviz.org/Resources.php for an archived copy.