andreas-vox/scribusctl

Official Scribus collaboration area for Complex Text Layout (RTL, CJK, Indic, OpenType, Math, CSS, ...)

scribusctl's Issues

#2128 "Cache font info for startup"

http://bugs.scribus.net/view.php?id=2128

@andreas-vox I added this because it may be related. You outlined some interesting ideas that sounds relevant.

Persian Language test in 1.5.1 svn

I try to test Persian ( Farsi ) language in 1.5.1svn, but it is still unclear. I install 1.5.1svn on fedora from :

https://copr.fedoraproject.org/coprs/luya/scribus-unstable/

traditional mongolian/uyghur vertical script.

I just discovered this nice project for Scribus and would like to know if the Mongolian traditional, vertical script will be managed? I know there is at least montex for LaTeX, and I suppose that's the good time to think to this. Perhaps it will be to complex to integrate at the same time and it will be for later.

I try here to explain as far I know about the script and computer methods to write/display in the hope it can be for interest in futur for this writing in open source ecosystem:

In Mongolian (Khalkha, national language) that's referred by "mongol bichig" (Mongolian script) or "caagan tolgoi" (white head), that's often referred in Occident by "traditional Mongolian script" or by "Uyghur script", as it was first used by old Uyghur alphabet (today they use near from arabian/persian script). Uyghur alphabet is derivated itself from old Sogdian/Syriac/Manichaean scripts) will be managed. There are other name for variants (as for Oirat, another Mongolian language, Tungustic languages (Manchu, Evenk...) and probably (not sure at all) more sporadically by some turkish ( in Tuva, Kyrgyzstan, Kazakhstan or some Turkish minorities of China).

That's a very special case in scripts, only used by few millions people in desert area today, mainly for Mongolian and Tungusic languages in China, or a little less in Mongolia and Eastern Russia republics, as Cyrillic officially replaced this writing in this countries. It is still used for special occasions like decorative/artistic (as calligraphy) in Mongolia/eastern Russia republics but keep used in special cases (mainly artistic one). This is probably a big work on this part, as this is among the last fully vertical writing in the world (Chinese, Japanese and Korean are used horizontally from left to right on computer now).

There is an UTF-8 (U+18xx)/Mongolian range for this script, that I suppose can manage every variants including old uyghur. Generally tricks are used on website, like using JavaScript or writing horizontally and then rotate the text by 90° (this has some side effects, has some font are designed vertically from start some other horizontally to be rotated and software can't know if that's one or the other of the cases). The encoding has also some variants for websites, probably coming from pre-UTF ou proto-UTF eras. I for now meet 3 cases:

1. Simply using UTF-8 Mongolian range
2. Using actual UTF-8 basic Latin range + a conversion (called CMS if I'm not wrong). That's allow to write using west European keyboards without IME.
3. Using mixing ranges symbols and ascriptive conversion

Before trying the following sites (some embed fonts), installing montext (included in texlive-lang-cyrillic on ubuntu), can be a good method to have mongolian fonts installed.

Else, this site have nice calligraphy/computer fonts links (or you can search at (CMs Ulaanbaatar font around the web):
http://luc.devroye.org/mongolian.html

A website using JavaScript dedicated to writing Mongolian (give UTF-8 Mongolian range result that can be copy-pasted) (1st method):
http://www.unsen-sambar.com/

An Inner-Mongolia site (about Mongolian wrestling) using traditional script with 3rd method:
http://www.mongolbuh.com/publish/

The Cyrillic Mongolian Wiktionary use the 2nd method (Latin characters coding) to display traditional Mongol script:
https://mn.wiktionary.org/wiki/эмээл#Монгол бичиг

an english/.../mongolian dictionary that uses UTF8 Mongolian, only displayed horizontally,:
http://www.bolor-toli.com/dictionary/word?authenticity_token=dYB8Y%2Btq0NBtTbIPt1l2X6bYx8ISYv5T%2FUFHEVRj1T8%3D&selected_lang=4-1&search=монгол

Wikipedia does the same on Firefox by default, try to display vertically with Chromium, sometimes little SVG pictures of vertical text are used inside text to resolve all those issues in wikipedia. For example in this French version of Hohhot (The capital of Inner-Monglia), you can see how is broken in infobox at right (if you have the font) (horizontal font turned vertically, but still displayed horizontally) :
https://fr.wikipedia.org/wiki/Hohhot

This en/mn dictionary display CMS definition, UTF8 traditional Mongolian and Cyrillic Mongolian variants of the words :
https://www.istb.univie.ac.at/mongol/mng/cyr/verif2.php

You can see here, than Latin characters are rotated 90° too (see the next link, I seen prints in Inner-Mongolia that look like this too) some time you have some foreign script turned left, some other turned right, that is probably good for neck exercises ;) ).
http://www.mongolbuh.com/publish/zoog/content/2014102110311212109.htm

So I believe today the most simple method is using Mongolian and wrote vertically (with probably an option to rotate or not characters ?) LaTеX could be a good reference. There is a specialized module called "montex – Mongolian LaTeX" (when searching for Mongolian, other packages are for cyrillic Mongolian script, that add some chars to the Russian or Bulgarian Cyrillic):
http://www.ctan.org/pkg/montex

A document about proposal to include birga (punctuation/head marks) symbols on UTF-8 that should contain some refs:
http://www.unicode.org/L2/L2014/14067-mongolian.pdf

Some tools exists for Android or iOS, I tried it on a rooted Samsung, but I had to wipe system, as Samsung interface doesn't manage at all vertical text, some buttons could not be pressed anymore, as far away from the screen display :D, so if someone want to get a try, save your data before...
http://www.mongolfont.com/
http://blog.163.com/baoshijie_2212/blog/static/1119047192012103024359913/

Some pictures of Mongolian writing, beside English and Chinese on street/road panels in Inner-Mongolia:
https://commons.wikimedia.org/wiki/Category:Signs_in_Mongolian_script

As references (for the fun, probably interesting for archaeology/history purposes) about the origins of this writing :
https://en.wikipedia.org/wiki/Old_Uyghur_alphabet
https://en.wikipedia.org/wiki/Sogdian_alphabet
https://en.wikipedia.org/wiki/Manichaean_alphabet
https://en.wikipedia.org/wiki/Syriac_alphabet

Elaborate on all phases of CTL implementation to encourage collaboration

• Phase 1 & Phase 2 will be worked on simultaneously (rationale: #3 (comment)). Phase 1: Make PDF production (+ PS production + svg-export) glyph based instead of character based. Phase 2: Separate StoryText from Layout (milestone)
  • class StoryText stores only the unicode, charstyle and special items like paragraph separators, inline objects and footnotes
  • a new class TextLayout stores the glyphs, their relations to the unicode text and their visual positioning
  • the visual positioning is represented by a tree of boxes, which come in several flavors: class GlyphBox for a sequence of glyphs which all have the same font and formatting, class LineBox for a sequence of glyphboxes, class BlockBox for a sequence of lineboxes, class InlineBox for embedded pageitems and other boxes for more fancy layout (if you know TeX you'll get the picture)
  • class TextLayout will also provide all methods for cursor positioning (next line, end of column, selection, screen coordinate to StoryText position mapping, ...)
  • Boxes will have a method render(ScPainterEx* painter)
  • The interface ScPainterEx will have a method drawGlyphs(const GlyphBox& glyphrun)
  • PS and PDF export will be implementations of the ScPainterEx interface.
• Phase 3: Integrate Harfbuzz (milestone) is an OpenType layout library. By using Harfbuzz we will enable features like:
  • Ligatures and language specific layouts.
  • With some luck we will even enable Indic shaping.
• Phase 4: Implement a box-oriented layout mechanism (milestone), i.e. store the layout as a hierarchy of boxes. Like in TeX and HTML, boxes can be arbitrarily nested.
  • Refactor TextLayout to store a hierarchy of boxes: GlyphBoxes store text, HBoxes store lines of text, VBoxes store paragraphs or similar structures.
  • Rendering code has to be adapted in order to handle this flexibility.
• Phase 5: Integrate Fribidi (milestone) is a library for layouting RTL (right-to-left) languages like Arabic, Hebrew and Persian.
  • Elaboration needed
• Phase 6: Expand the style system with CSS-like features
  • Elaboration needed

Pending Bugs #13093 #13240 related to ScribusCTL

http://bugs.scribus.net/view.php?id=13093
http://bugs.scribus.net/view.php?id=13240

build .spec file for rpm package

Hi,

I now building a .spec file for compiling and create scribusctl.rpm for use in fedora.

But I have a problem, I can't complete .spec file. .spec file need two option :

1- BuildRequires
2- Requires

more about options :

BuildRequires: A comma-separated list of packages required for building (compiling) the program. This field can be (and is commonly) repeated on multiple lines. These dependencies are not automatically determined, so you need to include everything needed to build the program. Some common packages can be omitted, such as gcc. You can specify a minimum version if necessary (e.g. "ocaml >= 3.08"). If you need the file /EGGS, determine the package that owns it by running "rpm -qf /EGGS". If you need the program EGGS, determine the package that owns it by running "rpm -qf which EGGS". Keep dependencies to a minimum (e.g. use sed instead of perl if you don't really need perl's abilities), but beware that some applications permanently disable functions if the associated dependency is not present; in those cases you may need to include the additional packages. The Package-x-generic-16.pngauto-buildrequires package may be helpful.

Requires: A comma-separate list of packages that are required when the program is installed. Note that the BuildRequires tag lists what is required to build the binary RPM, while the Requires tag lists what is required when installing/running the program; a package may be in one list or in both. In many cases, rpmbuild automatically detects dependencies so the Requires tag is not always necessary. However, you may wish to highlight some specific packages as being required, or they may not be automatically detected.

Please help me to complete .spec file.

Integrate Appveyor (Windows Continuous Integration)

Postponed

• Appveyor has no Qt library support for msvc2012 (see link)
• Won't support testing on XP

Background

Continuous Integration (CI) allows to trigger a build whenever a Pull Request (PR) is made to Scribus trunk. It has the potential to help the Scribus developers. Currently there is a working CI for Linux and one in process for OSX (see #2)
For Windows there is a 3rd party service that integrates in to Github called AppVeyor.

TODO

• Consult with the only person in the universe that can install bleeding edge Scribus on Windows (jghali)
• Appveyor's Installed software and libraries
• Up to date instructions for Building Scribus with msvc
• Find dependencies
  • Qt libs supported by appveyor
  • Rest of Scribus deps are on SF
• Build an appveyor.yml file

Useful references

• http://www.appveyor.com/docs/environment-variables

make errors on Ubuntu 16.04

Upon completing cmake successfully, I run make and get the following errors:

/home/tzvi/ScribusCTL/scribus/text/boxes.cpp:102:22: error: ‘m_gylphs’ was not declared in this scope
  for (int i = 0; i < m_gylphs.length(); ++i)
                      ^
/home/tzvi/ScribusCTL/scribus/text/boxes.cpp:104:17: error: ‘m_glyphs’ was not declared in this scope
   qreal width = m_glyphs[i].xadvance;
                 ^
/home/tzvi/ScribusCTL/scribus/text/boxes.cpp: In member function ‘virtual FRect GlyphBox::boundingBox(int, uint) const’:
/home/tzvi/ScribusCTL/scribus/text/boxes.cpp:117:27: error: invalid use of member function (did you forget the ‘()’ ?)
  int relPos = firstChar - pos;
                           ^
/home/tzvi/ScribusCTL/scribus/text/boxes.cpp:121:12: error: ‘m_glyphs’ was not declared in this scope
   xPos1 += m_glyphs[i].xadvance;
            ^
/home/tzvi/ScribusCTL/scribus/text/boxes.cpp:123:16: error: ‘m_glyphs’ was not declared in this scope
  qreal width = m_glyphs[relPos].xadvance;
                ^
/home/tzvi/ScribusCTL/scribus/text/boxes.cpp:125:29: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  for (int i = relPos + 1; i < pos + len; ++i)
                             ^
/home/tzvi/ScribusCTL/scribus/text/boxes.cpp:129:23: error: wrong type argument to unary minus
  return FRect(xPos1, -descent, xPos2 - xPos1, ascent);
                       ^
scribus/text/CMakeFiles/scribus_text_lib.dir/build.make:203: recipe for target 'scribus/text/CMakeFiles/scribus_text_lib.dir/boxes.cpp.o' failed
make[2]: *** [scribus/text/CMakeFiles/scribus_text_lib.dir/boxes.cpp.o] Error 1
CMakeFiles/Makefile2:468: recipe for target 'scribus/text/CMakeFiles/scribus_text_lib.dir/all' failed
make[1]: *** [scribus/text/CMakeFiles/scribus_text_lib.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

Translations of Scribus GUI for RTL, Indic, CJK before CTL is finished

Ideally, we'd have translations for Scribus UI to be complete before ScribusCTL is complete. We could use translators that have DTP experience and know how to translate technical terms in to their respective translated languages.

Languages:

• Arabic (Transifex link)
  • Coordinator @moceap
• Hindi
  • Coordinator needed
• Kannada (Transifex link)
  • Coordinator @sarathms
• Farsi
  • Coordinator needed
• Chinese (Transifex link)
  • Coordinator needed
• Japanese (Transifex link)
  • Coordinator @ftake
• Thai
  • Coordinator needed
• Hebrew (Transifex link)
  • Coordinator @luzpaz

Integrate Travis-CI

Changelog

• Sign up with Travis-CI (free for OSS Projects)
• Ability to trigger Travis CI through any PR or Push
• Figure out where the .travis.yml file will live (perhaps master branch? if and when Travis CI proves to be a good idea; talk to core-devs about putting it in trunk so it's mirrored to github?)
• Build result notifications through email, IRC and much more
• Write a .travis.yml file
  • Linux: @khaledhosny and @QuLogic have created a .yml script for 14.04
  • OSX: @luzpaz is still developing a [.travis.yml file @ https://github.com/scribusproject/scribus/pull/29) for OSX
  • Windows: appveyor.yml to be used. See #9

Integrate different tests

• Every so often trigger a Coverty scan through Travis CI
• Follow up with bugtracker issues Automated "black box" test suite
• Integrate Regression Testing at some point (scribusproject/scribus#18)
• Think of new tests

Mirrored issue at scribusproject/scribus#3
Copied from original issue: scribusproject/scribus#3

RTL Branch compile warning

[ 23%] Generating moc_pdflib.cpp
/tmp/scribusrtl20150808-11101-1yshgn0/scribus/shaper.h:0: Note: No relevant classes found. No output generated.

OSX 10.10.4 running latest RTL branch

FLOSS supporters who may be willing to test ScribusCTL

Possible folks that would be interested in ScribusCTL:
@fossasia, @mariobehling, @msm1365,

fjtake

Fatal error: 'ext/slist' file not found

Hey @andreas-vox
Please update with trunk as craig fixed this error in r20127
``
In file included from /tmp/scribusctl20150528-71786-e82fco/scribus/third_party/prc/oPRCFile.cc:22:
In file included from /tmp/scribusctl20150528-71786-e82fco/scribus/third_party/prc/oPRCFile.h:40:
/tmp/scribusctl20150528-71786-e82fco/scribus/third_party/prc/writePRC.h:28:10: fatal error: 'ext/slist' file not found

include <ext/slist>

     ^

Linking CXX static library libscribus_fonts_lib.a
``