Re: Introduction of a "type mode" and an "unicode mode" of input

[Samiur Rahman]

The box should actually say "“Choose character set."

On Sat, Jul 2, 2016 at 8:45 PM, Samiur Rahman  wrote:

> I'm fixing a few mistakes.
>
> > And yes, free non-unicode fonts that support any range of unicode, such
> as a
> > language or script, should come with Calligra.
>
> "Maybe on Windows or Mac. Because on Linux font files are typically a
> property of operating systems."
>
> It's easy to install fonts to the OS, at least in Windows, and can be one
> by any application or by the user. I've done it personally on Windows and
> Linux, and I believe Adobe applications do install new fonts on the system.
>
>
> "Usually, we presume that the user needs only characters for Western
> European and operating systems and office suites come only with fonts for
> that range of unicode. "
>
> Like above, I don't see how is that true after MS DOS already. Or even
> with MS DOS or old UNIX had cyrillic and japanese sets. If I understand
> you properly.
>
> OSs may come with fonts for Japanese or Cyrillic but not all languages and
> scripts. Either OSs or applications should come with: all free
> script-specific fonts and all free Unicode fonts.
>
>
> My idea was to:
>
>
>
>1.
>
>Add the box “Choose character range” in the application
>2.
>
>Package free fonts that serve any unicode range and all free unicode
>fonts
>
>
> Eventually, the second may be served by the OS, but the first has to be,
> and the second can be started by the application.
>
>
> Thanks all.
>
> On Sat, Jul 2, 2016 at 8:16 PM, Samiur Rahman  wrote:
>
>> > And yes, free non-unicode fonts that support any range of unicode, such
>> as a
>> > language or script, should come with Calligra.
>>
>> "Maybe on Windows or Mac. Because on Linux font files are typically a
>> property of operating systems."
>>
>> It's easy to install fonts to the OS, at least in Windows, and can be one
>> by any application or by the user. Honestly, I've never done it on Windows
>> or Mac though.
>>
>>
>> "Usually, we presume that the user needs only characters for Western
>> European and operating systems and office suites come only with fonts
>> for that range of unicode. "
>>
>> Like above, I don't see how is that true after MS DOS already. Or even
>> with MS DOS or old UNIX had cyrillic and japanese sets. If I understand
>> you properly.
>>
>> OSs may come with fonts for Japanese or Cyrillic but not all languages
>> and scripts. Either OSs or applications should come with: all free
>> script-specific fonts and all free Unicode fonts.
>>
>>
>> My idea was to:
>>
>>
>>
>>1.
>>
>>Add the box “Choose unicode range” in the application
>>2.
>>
>>Package free fonts that serve any unicode range and all free unicode
>>fonts
>>
>>
>> Eventually, the second may be served by the OS, but the first has to be,
>> and the second can be started by the application.
>>
>>
>> Thanks,
>>
>> Samiur
>>
>> On Sat, Jul 2, 2016 at 7:51 PM, Jaroslaw Staniek  wrote:
>>
>>> On 3 July 2016 at 01:37, Samiur Rahman  wrote:
>>> > And yes, free non-unicode fonts that support any range of unicode,
>>> such as a
>>> > language or script, should come with Calligra.
>>>
>>> Maybe on Windows or Mac. Because on Linux font files are typically a
>>> property of operating systems.
>>>
>>> "Usually, we presume that the user needs only characters for Western
>>> European and operating systems and office suites come only with fonts
>>> for that range of unicode. "
>>>
>>> Like above, I don't see how is that true after MS DOS already. Or even
>>> with MS DOS or old UNIX had cyrillic and japanese sets. If I
>>> understand you properly.
>>>
>>> If there's something missing a proper address to send requests is 1.
>>> operating system vendors (even if you mean Linux) and 2. projects that
>>> work on fonts (if you mean about free fonts). Calligra as a project
>>> does not and should not ship general purpose fonts as such if they are
>>> part of the OS.
>>> At least two classes of exceptions are:
>>> - we have dedicated fonts for example for music notation in a Music
>>> Shape or specific formula/math symbols
>>> - to make sure fonts *normally* available in modern free operating
>>> systems are also available on Windows or Mac, the files (if it's 100%
>>> legal) may be packaged with Calligra apps to overcome the misfeature
>>>
>>> Contributions to such packaging is of course welcome. I've heard there
>>> are efforts to package Calligra 3 app(s) on non-Linux. It's typical
>>> that fixes to this area come from the interested parties able to try
>>> real/specific use cases.
>>>
>>> >
>>> > On Sat, Jul 2, 2016 at 7:35 PM, Samiur Rahman 
>>> wrote:
>>> >>
>>> >> What I see is that if it's a practice to include all free unicode
>>> fonts in
>>> >> an office suite, in order to use them commonly, all office suites,
>>> even
>>> >> operating systems, must come with them. But it's a good practice to

Re: Introduction of a "type mode" and an "unicode mode" of input

[Samiur Rahman]

I'm fixing a few mistakes.

> And yes, free non-unicode fonts that support any range of unicode, such
as a
> language or script, should come with Calligra.

"Maybe on Windows or Mac. Because on Linux font files are typically a
property of operating systems."

It's easy to install fonts to the OS, at least in Windows, and can be one
by any application or by the user. I've done it personally on Windows and
Linux, and I believe Adobe applications do install new fonts on the system.


"Usually, we presume that the user needs only characters for Western
European and operating systems and office suites come only with fonts for
that range of unicode. "

Like above, I don't see how is that true after MS DOS already. Or even with
MS DOS or old UNIX had cyrillic and japanese sets. If I understand you
properly.

OSs may come with fonts for Japanese or Cyrillic but not all languages and
scripts. Either OSs or applications should come with: all free
script-specific fonts and all free Unicode fonts.


My idea was to:



   1.

   Add the box “Choose character range” in the application
   2.

   Package free fonts that serve any unicode range and all free unicode
   fonts


Eventually, the second may be served by the OS, but the first has to be,
and the second can be started by the application.


Thanks all.

On Sat, Jul 2, 2016 at 8:16 PM, Samiur Rahman  wrote:

> > And yes, free non-unicode fonts that support any range of unicode, such
> as a
> > language or script, should come with Calligra.
>
> "Maybe on Windows or Mac. Because on Linux font files are typically a
> property of operating systems."
>
> It's easy to install fonts to the OS, at least in Windows, and can be one
> by any application or by the user. Honestly, I've never done it on Windows
> or Mac though.
>
>
> "Usually, we presume that the user needs only characters for Western
> European and operating systems and office suites come only with fonts for
> that range of unicode. "
>
> Like above, I don't see how is that true after MS DOS already. Or even
> with MS DOS or old UNIX had cyrillic and japanese sets. If I understand
> you properly.
>
> OSs may come with fonts for Japanese or Cyrillic but not all languages and
> scripts. Either OSs or applications should come with: all free
> script-specific fonts and all free Unicode fonts.
>
>
> My idea was to:
>
>
>
>1.
>
>Add the box “Choose unicode range” in the application
>2.
>
>Package free fonts that serve any unicode range and all free unicode
>fonts
>
>
> Eventually, the second may be served by the OS, but the first has to be,
> and the second can be started by the application.
>
>
> Thanks,
>
> Samiur
>
> On Sat, Jul 2, 2016 at 7:51 PM, Jaroslaw Staniek  wrote:
>
>> On 3 July 2016 at 01:37, Samiur Rahman  wrote:
>> > And yes, free non-unicode fonts that support any range of unicode, such
>> as a
>> > language or script, should come with Calligra.
>>
>> Maybe on Windows or Mac. Because on Linux font files are typically a
>> property of operating systems.
>>
>> "Usually, we presume that the user needs only characters for Western
>> European and operating systems and office suites come only with fonts
>> for that range of unicode. "
>>
>> Like above, I don't see how is that true after MS DOS already. Or even
>> with MS DOS or old UNIX had cyrillic and japanese sets. If I
>> understand you properly.
>>
>> If there's something missing a proper address to send requests is 1.
>> operating system vendors (even if you mean Linux) and 2. projects that
>> work on fonts (if you mean about free fonts). Calligra as a project
>> does not and should not ship general purpose fonts as such if they are
>> part of the OS.
>> At least two classes of exceptions are:
>> - we have dedicated fonts for example for music notation in a Music
>> Shape or specific formula/math symbols
>> - to make sure fonts *normally* available in modern free operating
>> systems are also available on Windows or Mac, the files (if it's 100%
>> legal) may be packaged with Calligra apps to overcome the misfeature
>>
>> Contributions to such packaging is of course welcome. I've heard there
>> are efforts to package Calligra 3 app(s) on non-Linux. It's typical
>> that fixes to this area come from the interested parties able to try
>> real/specific use cases.
>>
>> >
>> > On Sat, Jul 2, 2016 at 7:35 PM, Samiur Rahman 
>> wrote:
>> >>
>> >> What I see is that if it's a practice to include all free unicode
>> fonts in
>> >> an office suite, in order to use them commonly, all office suites, even
>> >> operating systems, must come with them. But it's a good practice to
>> start
>> >> on. Usually, we presume that the user needs only characters for Western
>> >> European and operating systems and office suites come only with fonts
>> for
>> >> that range of unicode. What I suggest is to include all free unicode
>> fonts
>> >> in Calligra, to cater to users of all 

Re: Introduction of a "type mode" and an "unicode mode" of input

[Samiur Rahman]

> And yes, free non-unicode fonts that support any range of unicode, such
as a
> language or script, should come with Calligra.

"Maybe on Windows or Mac. Because on Linux font files are typically a
property of operating systems."

It's easy to install fonts to the OS, at least in Windows, and can be one
by any application or by the user. Honestly, I've never done it on Windows
or Mac though.


"Usually, we presume that the user needs only characters for Western
European and operating systems and office suites come only with fonts for
that range of unicode. "

Like above, I don't see how is that true after MS DOS already. Or even with
MS DOS or old UNIX had cyrillic and japanese sets. If I understand you
properly.

OSs may come with fonts for Japanese or Cyrillic but not all languages and
scripts. Either OSs or applications should come with: all free
script-specific fonts and all free Unicode fonts.


My idea was to:



   1.

   Add the box “Choose unicode range” in the application
   2.

   Package free fonts that serve any unicode range and all free unicode
   fonts


Eventually, the second may be served by the OS, but the first has to be,
and the second can be started by the application.


Thanks,

Samiur

On Sat, Jul 2, 2016 at 7:51 PM, Jaroslaw Staniek  wrote:

> On 3 July 2016 at 01:37, Samiur Rahman  wrote:
> > And yes, free non-unicode fonts that support any range of unicode, such
> as a
> > language or script, should come with Calligra.
>
> Maybe on Windows or Mac. Because on Linux font files are typically a
> property of operating systems.
>
> "Usually, we presume that the user needs only characters for Western
> European and operating systems and office suites come only with fonts
> for that range of unicode. "
>
> Like above, I don't see how is that true after MS DOS already. Or even
> with MS DOS or old UNIX had cyrillic and japanese sets. If I
> understand you properly.
>
> If there's something missing a proper address to send requests is 1.
> operating system vendors (even if you mean Linux) and 2. projects that
> work on fonts (if you mean about free fonts). Calligra as a project
> does not and should not ship general purpose fonts as such if they are
> part of the OS.
> At least two classes of exceptions are:
> - we have dedicated fonts for example for music notation in a Music
> Shape or specific formula/math symbols
> - to make sure fonts *normally* available in modern free operating
> systems are also available on Windows or Mac, the files (if it's 100%
> legal) may be packaged with Calligra apps to overcome the misfeature
>
> Contributions to such packaging is of course welcome. I've heard there
> are efforts to package Calligra 3 app(s) on non-Linux. It's typical
> that fixes to this area come from the interested parties able to try
> real/specific use cases.
>
> >
> > On Sat, Jul 2, 2016 at 7:35 PM, Samiur Rahman 
> wrote:
> >>
> >> What I see is that if it's a practice to include all free unicode fonts
> in
> >> an office suite, in order to use them commonly, all office suites, even
> >> operating systems, must come with them. But it's a good practice to
> start
> >> on. Usually, we presume that the user needs only characters for Western
> >> European and operating systems and office suites come only with fonts
> for
> >> that range of unicode. What I suggest is to include all free unicode
> fonts
> >> in Calligra, to cater to users of all scripts and languages.
> >>
> >> Thanks.
> >>
> >> On Sat, Jul 2, 2016 at 7:27 PM, Jaroslaw Staniek 
> wrote:
> >>>
> >>> On 3 July 2016 at 01:11, Samiur Rahman  wrote:
> >>> > Jaroslaw wrote: "If so, as such place for its implementation isn't at
> >>> > Calligra level but at a computer operating system's level, even above
> >>> > Qt
> >>> > itself."
> >>> >
> >>> > You can select to type in your keyboard, by selecting your keyboard
> in
> >>> > the
> >>> > OS, but usually you need to buy or maybe possibly download a font for
> >>> > your
> >>> > language or script. The benefit of a "unicode mode" as an input mode
> in
> >>> > the
> >>> > office app is that you don't need to buy or download that font.
> >>> >
> >>> > Camilla wrote: "we have a dialog that allows you to enter specific
> >>> > charactes
> >>> > from any unicode range"
> >>> >
> >>> > But you can't actually "type" using those characters that you can
> >>> > choose as
> >>> > special characters.
> >>>
> >>> What special characters do you mean?
> >>>
> >>>
> >>> "Users should select an unicode range, such as Greek or Cyrillic,"
> >>>
> >>> To avoid mixing separate things: input methods, unicode representation
> >>> and file formats,
> >>> please let me mention that:
> >>>
> >>> - language and font is an attribute of character in ODF and MSOOXML
> >>> and older MS formats, all that is specified and not subject to change
> >>> (and especially a change here instead of change in input method 

Re: Introduction of a "type mode" and an "unicode mode" of input

[Jaroslaw Staniek]

On 3 July 2016 at 01:37, Samiur Rahman  wrote:
> And yes, free non-unicode fonts that support any range of unicode, such as a
> language or script, should come with Calligra.

Maybe on Windows or Mac. Because on Linux font files are typically a
property of operating systems.

"Usually, we presume that the user needs only characters for Western
European and operating systems and office suites come only with fonts
for that range of unicode. "

Like above, I don't see how is that true after MS DOS already. Or even
with MS DOS or old UNIX had cyrillic and japanese sets. If I
understand you properly.

If there's something missing a proper address to send requests is 1.
operating system vendors (even if you mean Linux) and 2. projects that
work on fonts (if you mean about free fonts). Calligra as a project
does not and should not ship general purpose fonts as such if they are
part of the OS.
At least two classes of exceptions are:
- we have dedicated fonts for example for music notation in a Music
Shape or specific formula/math symbols
- to make sure fonts *normally* available in modern free operating
systems are also available on Windows or Mac, the files (if it's 100%
legal) may be packaged with Calligra apps to overcome the misfeature

Contributions to such packaging is of course welcome. I've heard there
are efforts to package Calligra 3 app(s) on non-Linux. It's typical
that fixes to this area come from the interested parties able to try
real/specific use cases.

>
> On Sat, Jul 2, 2016 at 7:35 PM, Samiur Rahman  wrote:
>>
>> What I see is that if it's a practice to include all free unicode fonts in
>> an office suite, in order to use them commonly, all office suites, even
>> operating systems, must come with them. But it's a good practice to start
>> on. Usually, we presume that the user needs only characters for Western
>> European and operating systems and office suites come only with fonts for
>> that range of unicode. What I suggest is to include all free unicode fonts
>> in Calligra, to cater to users of all scripts and languages.
>>
>> Thanks.
>>
>> On Sat, Jul 2, 2016 at 7:27 PM, Jaroslaw Staniek  wrote:
>>>
>>> On 3 July 2016 at 01:11, Samiur Rahman  wrote:
>>> > Jaroslaw wrote: "If so, as such place for its implementation isn't at
>>> > Calligra level but at a computer operating system's level, even above
>>> > Qt
>>> > itself."
>>> >
>>> > You can select to type in your keyboard, by selecting your keyboard in
>>> > the
>>> > OS, but usually you need to buy or maybe possibly download a font for
>>> > your
>>> > language or script. The benefit of a "unicode mode" as an input mode in
>>> > the
>>> > office app is that you don't need to buy or download that font.
>>> >
>>> > Camilla wrote: "we have a dialog that allows you to enter specific
>>> > charactes
>>> > from any unicode range"
>>> >
>>> > But you can't actually "type" using those characters that you can
>>> > choose as
>>> > special characters.
>>>
>>> What special characters do you mean?
>>>
>>>
>>> "Users should select an unicode range, such as Greek or Cyrillic,"
>>>
>>> To avoid mixing separate things: input methods, unicode representation
>>> and file formats,
>>> please let me mention that:
>>>
>>> - language and font is an attribute of character in ODF and MSOOXML
>>> and older MS formats, all that is specified and not subject to change
>>> (and especially a change here instead of change in input method would
>>> be the least likely approved)
>>>
>>> - the modes of input is separate from application; applications
>>> receive ready to interpret logical input events prepared by the input
>>> method based on lower level events (key, voice, whatever); for example
>>> there were times when I've been using Hangul for testing of input
>>> methods; given input method just composed entire syllables out of
>>> atomic key strokes - apps have never "seen" separate key strokes, only
>>> syllables, each having own number in the Unicode standard. This is why
>>> I think that whatever you design like two boxes of input, this belongs
>>> to the outside of application, to the input method system
>>>
>>> - fonts: separate topic again, their *cost* and so on - it can be all
>>> addressed by working on libre implementation of fonts that given
>>> nations/cultures need; that's a proper level of activity
>>>
>>> (if I understand correctly)
>>>
>>> Finally I think an animation or mockup of your proposed method would
>>> increase chances to find more interest.
>>>
>>>
>>> > Camille also wrote: "yes it is true that the font used to show the text
>>> > has
>>> > to support the script. But a few free unicode fonts do exist already."
>>> >
>>> > A few unicode fonts do exist but only Arial Unicode MS commonly comes
>>> > with
>>> > Windows, I don't know what Linux makes available. The best way to use
>>> > them,
>>> > as I see it, is to implement the "unicode mode" of input in the office

Re: Introduction of a "type mode" and an "unicode mode" of input

[Samiur Rahman]

And yes, free non-unicode fonts that support any range of unicode, such as
a language or script, should come with Calligra.

On Sat, Jul 2, 2016 at 7:35 PM, Samiur Rahman  wrote:

> What I see is that if it's a practice to include all free unicode fonts in
> an office suite, in order to use them commonly, all office suites, even
> operating systems, must come with them. But it's a good practice to start
> on. Usually, we presume that the user needs only characters for Western
> European and operating systems and office suites come only with fonts for
> that range of unicode. What I suggest is to include all free unicode fonts
> in Calligra, to cater to users of all scripts and languages.
>
> Thanks.
>
> On Sat, Jul 2, 2016 at 7:27 PM, Jaroslaw Staniek  wrote:
>
>> On 3 July 2016 at 01:11, Samiur Rahman  wrote:
>> > Jaroslaw wrote: "If so, as such place for its implementation isn't at
>> > Calligra level but at a computer operating system's level, even above Qt
>> > itself."
>> >
>> > You can select to type in your keyboard, by selecting your keyboard in
>> the
>> > OS, but usually you need to buy or maybe possibly download a font for
>> your
>> > language or script. The benefit of a "unicode mode" as an input mode in
>> the
>> > office app is that you don't need to buy or download that font.
>> >
>> > Camilla wrote: "we have a dialog that allows you to enter specific
>> charactes
>> > from any unicode range"
>> >
>> > But you can't actually "type" using those characters that you can
>> choose as
>> > special characters.
>>
>> What special characters do you mean?
>>
>>
>> "Users should select an unicode range, such as Greek or Cyrillic,"
>>
>> To avoid mixing separate things: input methods, unicode representation
>> and file formats,
>> please let me mention that:
>>
>> - language and font is an attribute of character in ODF and MSOOXML
>> and older MS formats, all that is specified and not subject to change
>> (and especially a change here instead of change in input method would
>> be the least likely approved)
>>
>> - the modes of input is separate from application; applications
>> receive ready to interpret logical input events prepared by the input
>> method based on lower level events (key, voice, whatever); for example
>> there were times when I've been using Hangul for testing of input
>> methods; given input method just composed entire syllables out of
>> atomic key strokes - apps have never "seen" separate key strokes, only
>> syllables, each having own number in the Unicode standard. This is why
>> I think that whatever you design like two boxes of input, this belongs
>> to the outside of application, to the input method system
>>
>> - fonts: separate topic again, their *cost* and so on - it can be all
>> addressed by working on libre implementation of fonts that given
>> nations/cultures need; that's a proper level of activity
>>
>> (if I understand correctly)
>>
>> Finally I think an animation or mockup of your proposed method would
>> increase chances to find more interest.
>>
>>
>> > Camille also wrote: "yes it is true that the font used to show the text
>> has
>> > to support the script. But a few free unicode fonts do exist already."
>> >
>> > A few unicode fonts do exist but only Arial Unicode MS commonly comes
>> with
>> > Windows, I don't know what Linux makes available. The best way to use
>> them,
>> > as I see it, is to implement the "unicode mode" of input in the office
>> > applications, with the two boxes "choose unicodfoe range" and "choose
>> > unicode font," in which you first specify which range you are typing
>> it, and
>> > then choose from a number of fonts that support that range.
>> >
>> > Thanks.
>> >
>> > On Sat, Jul 2, 2016 at 6:40 PM, Camilla Boemann  wrote:
>> >>
>> >> Hi
>> >>
>> >> I don't  understand this either.
>> >>
>> >> 1) all text in calligra is unicode
>> >> 2) we have a dialog that allows you to enter specific charactes from
>> any
>> >> unicode range
>> >> 3) yes it is true that the font used to show the text has to support
>> the
>> >> script. But a few free unicode fonts do exist already
>> >>
>> >> On Saturday 02 July 2016 15:13:03 Huxshathra Theudanaz wrote:
>> >> > A distinction between two types of input, a "type mode" and an
>> "unicode
>> >> > mode" in all Calligra applications. In "unicode mode," there should
>> be
>> >> > two
>> >> > boxes, one that asks to "choose unicodfoe range" and the other that
>> asks
>> >> > to
>> >> > "choose unicode font." Users should select an unicode range, such as
>> >> > Greek
>> >> > or Cyrillic, and then choose from a number of unicode fonts, which
>> >> > should
>> >> > come with Calligra, that support that range.
>> >> >
>> >> > "Type mode" and "unicode mode" are different even now. If someone
>> wants
>> >> > to
>> >> > type in non-Western European characters, they usually type in "type
>> >> > mode"
>> >> > using fonts they buy. Another 

Re: Introduction of a "type mode" and an "unicode mode" of input

[Samiur Rahman]

What I see is that if it's a practice to include all free unicode fonts in
an office suite, in order to use them commonly, all office suites, even
operating systems, must come with them. But it's a good practice to start
on. Usually, we presume that the user needs only characters for Western
European and operating systems and office suites come only with fonts for
that range of unicode. What I suggest is to include all free unicode fonts
in Calligra, to cater to users of all scripts and languages.

Thanks.

On Sat, Jul 2, 2016 at 7:27 PM, Jaroslaw Staniek  wrote:

> On 3 July 2016 at 01:11, Samiur Rahman  wrote:
> > Jaroslaw wrote: "If so, as such place for its implementation isn't at
> > Calligra level but at a computer operating system's level, even above Qt
> > itself."
> >
> > You can select to type in your keyboard, by selecting your keyboard in
> the
> > OS, but usually you need to buy or maybe possibly download a font for
> your
> > language or script. The benefit of a "unicode mode" as an input mode in
> the
> > office app is that you don't need to buy or download that font.
> >
> > Camilla wrote: "we have a dialog that allows you to enter specific
> charactes
> > from any unicode range"
> >
> > But you can't actually "type" using those characters that you can choose
> as
> > special characters.
>
> What special characters do you mean?
>
>
> "Users should select an unicode range, such as Greek or Cyrillic,"
>
> To avoid mixing separate things: input methods, unicode representation
> and file formats,
> please let me mention that:
>
> - language and font is an attribute of character in ODF and MSOOXML
> and older MS formats, all that is specified and not subject to change
> (and especially a change here instead of change in input method would
> be the least likely approved)
>
> - the modes of input is separate from application; applications
> receive ready to interpret logical input events prepared by the input
> method based on lower level events (key, voice, whatever); for example
> there were times when I've been using Hangul for testing of input
> methods; given input method just composed entire syllables out of
> atomic key strokes - apps have never "seen" separate key strokes, only
> syllables, each having own number in the Unicode standard. This is why
> I think that whatever you design like two boxes of input, this belongs
> to the outside of application, to the input method system
>
> - fonts: separate topic again, their *cost* and so on - it can be all
> addressed by working on libre implementation of fonts that given
> nations/cultures need; that's a proper level of activity
>
> (if I understand correctly)
>
> Finally I think an animation or mockup of your proposed method would
> increase chances to find more interest.
>
>
> > Camille also wrote: "yes it is true that the font used to show the text
> has
> > to support the script. But a few free unicode fonts do exist already."
> >
> > A few unicode fonts do exist but only Arial Unicode MS commonly comes
> with
> > Windows, I don't know what Linux makes available. The best way to use
> them,
> > as I see it, is to implement the "unicode mode" of input in the office
> > applications, with the two boxes "choose unicodfoe range" and "choose
> > unicode font," in which you first specify which range you are typing it,
> and
> > then choose from a number of fonts that support that range.
> >
> > Thanks.
> >
> > On Sat, Jul 2, 2016 at 6:40 PM, Camilla Boemann  wrote:
> >>
> >> Hi
> >>
> >> I don't  understand this either.
> >>
> >> 1) all text in calligra is unicode
> >> 2) we have a dialog that allows you to enter specific charactes from any
> >> unicode range
> >> 3) yes it is true that the font used to show the text has to support the
> >> script. But a few free unicode fonts do exist already
> >>
> >> On Saturday 02 July 2016 15:13:03 Huxshathra Theudanaz wrote:
> >> > A distinction between two types of input, a "type mode" and an
> "unicode
> >> > mode" in all Calligra applications. In "unicode mode," there should be
> >> > two
> >> > boxes, one that asks to "choose unicodfoe range" and the other that
> asks
> >> > to
> >> > "choose unicode font." Users should select an unicode range, such as
> >> > Greek
> >> > or Cyrillic, and then choose from a number of unicode fonts, which
> >> > should
> >> > come with Calligra, that support that range.
> >> >
> >> > "Type mode" and "unicode mode" are different even now. If someone
> wants
> >> > to
> >> > type in non-Western European characters, they usually type in "type
> >> > mode"
> >> > using fonts they buy. Another option is to type in an unicode font
> such
> >> > as
> >> > Arial Unicode MS, and the other unicode fonts are obscure. As one
> plus,
> >> > "unicode mode" of input will allow these typists to type in their
> >> > language
> >> > or script without having at buy extra fonts.
> >> >
> >> > Plus word processors and email clients and 

Re: Introduction of a "type mode" and an "unicode mode" of input

[Jaroslaw Staniek]

On 3 July 2016 at 01:11, Samiur Rahman  wrote:
> Jaroslaw wrote: "If so, as such place for its implementation isn't at
> Calligra level but at a computer operating system's level, even above Qt
> itself."
>
> You can select to type in your keyboard, by selecting your keyboard in the
> OS, but usually you need to buy or maybe possibly download a font for your
> language or script. The benefit of a "unicode mode" as an input mode in the
> office app is that you don't need to buy or download that font.
>
> Camilla wrote: "we have a dialog that allows you to enter specific charactes
> from any unicode range"
>
> But you can't actually "type" using those characters that you can choose as
> special characters.

What special characters do you mean?


"Users should select an unicode range, such as Greek or Cyrillic,"

To avoid mixing separate things: input methods, unicode representation
and file formats,
please let me mention that:

- language and font is an attribute of character in ODF and MSOOXML
and older MS formats, all that is specified and not subject to change
(and especially a change here instead of change in input method would
be the least likely approved)

- the modes of input is separate from application; applications
receive ready to interpret logical input events prepared by the input
method based on lower level events (key, voice, whatever); for example
there were times when I've been using Hangul for testing of input
methods; given input method just composed entire syllables out of
atomic key strokes - apps have never "seen" separate key strokes, only
syllables, each having own number in the Unicode standard. This is why
I think that whatever you design like two boxes of input, this belongs
to the outside of application, to the input method system

- fonts: separate topic again, their *cost* and so on - it can be all
addressed by working on libre implementation of fonts that given
nations/cultures need; that's a proper level of activity

(if I understand correctly)

Finally I think an animation or mockup of your proposed method would
increase chances to find more interest.


> Camille also wrote: "yes it is true that the font used to show the text has
> to support the script. But a few free unicode fonts do exist already."
>
> A few unicode fonts do exist but only Arial Unicode MS commonly comes with
> Windows, I don't know what Linux makes available. The best way to use them,
> as I see it, is to implement the "unicode mode" of input in the office
> applications, with the two boxes "choose unicodfoe range" and "choose
> unicode font," in which you first specify which range you are typing it, and
> then choose from a number of fonts that support that range.
>
> Thanks.
>
> On Sat, Jul 2, 2016 at 6:40 PM, Camilla Boemann  wrote:
>>
>> Hi
>>
>> I don't  understand this either.
>>
>> 1) all text in calligra is unicode
>> 2) we have a dialog that allows you to enter specific charactes from any
>> unicode range
>> 3) yes it is true that the font used to show the text has to support the
>> script. But a few free unicode fonts do exist already
>>
>> On Saturday 02 July 2016 15:13:03 Huxshathra Theudanaz wrote:
>> > A distinction between two types of input, a "type mode" and an "unicode
>> > mode" in all Calligra applications. In "unicode mode," there should be
>> > two
>> > boxes, one that asks to "choose unicodfoe range" and the other that asks
>> > to
>> > "choose unicode font." Users should select an unicode range, such as
>> > Greek
>> > or Cyrillic, and then choose from a number of unicode fonts, which
>> > should
>> > come with Calligra, that support that range.
>> >
>> > "Type mode" and "unicode mode" are different even now. If someone wants
>> > to
>> > type in non-Western European characters, they usually type in "type
>> > mode"
>> > using fonts they buy. Another option is to type in an unicode font such
>> > as
>> > Arial Unicode MS, and the other unicode fonts are obscure. As one plus,
>> > "unicode mode" of input will allow these typists to type in their
>> > language
>> > or script without having at buy extra fonts.
>> >
>> > Plus word processors and email clients and apps usually do distinguish
>> > between "type" and "unicode." This feature will fully allow someone to
>> > type, create, and share documents in unicode.
>>
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>



-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - 

Re: Introduction of a "type mode" and an "unicode mode" of input

[Samiur Rahman]

I now see it clearly: Even when you use fonts that you buy, they just
generate a glyph for an unicode character. The good thing about what I
suggest is that you don't actually need to buy that font, the free unicode
font can cover that. So the user just selects "choose character range,"
which is Western European or any other, and then "choose font."

On Sat, Jul 2, 2016 at 7:11 PM, Samiur Rahman  wrote:

> Jaroslaw wrote: "If so, as such place for its implementation isn't at
> Calligra level but at a computer operating system's level, even above Qt
> itself."
>
> You can select to type in your keyboard, by selecting your keyboard in the
> OS, but usually you need to buy or maybe possibly download a font for your
> language or script. The benefit of a "unicode mode" as an input mode in the
> office app is that you don't need to buy or download that font.
>
> Camilla wrote: "we have a dialog that allows you to enter specific
> charactes from any unicode range"
>
> But you can't actually "type" using those characters that you can choose
> as special characters.
>
> Camille also wrote: "yes it is true that the font used to show the text
> has to support the script. But a few free unicode fonts do exist already."
>
> A few unicode fonts do exist but only Arial Unicode MS commonly comes with
> Windows, I don't know what Linux makes available. The best way to use them,
> as I see it, is to implement the "unicode mode" of input in the office
> applications, with the two boxes "choose unicodfoe range" and "choose
> unicode font," in which you first specify which range you are typing it,
> and then choose from a number of fonts that support that range.
>
> Thanks.
>
> On Sat, Jul 2, 2016 at 6:40 PM, Camilla Boemann  wrote:
>
>> Hi
>>
>> I don't  understand this either.
>>
>> 1) all text in calligra is unicode
>> 2) we have a dialog that allows you to enter specific charactes from any
>> unicode range
>> 3) yes it is true that the font used to show the text has to support the
>> script. But a few free unicode fonts do exist already
>>
>> On Saturday 02 July 2016 15:13:03 Huxshathra Theudanaz wrote:
>> > A distinction between two types of input, a "type mode" and an "unicode
>> > mode" in all Calligra applications. In "unicode mode," there should be
>> two
>> > boxes, one that asks to "choose unicodfoe range" and the other that
>> asks to
>> > "choose unicode font." Users should select an unicode range, such as
>> Greek
>> > or Cyrillic, and then choose from a number of unicode fonts, which
>> should
>> > come with Calligra, that support that range.
>> >
>> > "Type mode" and "unicode mode" are different even now. If someone wants
>> to
>> > type in non-Western European characters, they usually type in "type
>> mode"
>> > using fonts they buy. Another option is to type in an unicode font such
>> as
>> > Arial Unicode MS, and the other unicode fonts are obscure. As one plus,
>> > "unicode mode" of input will allow these typists to type in their
>> language
>> > or script without having at buy extra fonts.
>> >
>> > Plus word processors and email clients and apps usually do distinguish
>> > between "type" and "unicode." This feature will fully allow someone to
>> > type, create, and share documents in unicode.
>>
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Introduction of a "type mode" and an "unicode mode" of input

[Samiur Rahman]

Jaroslaw wrote: "If so, as such place for its implementation isn't at
Calligra level but at a computer operating system's level, even above Qt
itself."

You can select to type in your keyboard, by selecting your keyboard in the
OS, but usually you need to buy or maybe possibly download a font for your
language or script. The benefit of a "unicode mode" as an input mode in the
office app is that you don't need to buy or download that font.

Camilla wrote: "we have a dialog that allows you to enter specific
charactes from any unicode range"

But you can't actually "type" using those characters that you can choose as
special characters.

Camille also wrote: "yes it is true that the font used to show the text has
to support the script. But a few free unicode fonts do exist already."

A few unicode fonts do exist but only Arial Unicode MS commonly comes with
Windows, I don't know what Linux makes available. The best way to use them,
as I see it, is to implement the "unicode mode" of input in the office
applications, with the two boxes "choose unicodfoe range" and "choose
unicode font," in which you first specify which range you are typing it,
and then choose from a number of fonts that support that range.

Thanks.

On Sat, Jul 2, 2016 at 6:40 PM, Camilla Boemann  wrote:

> Hi
>
> I don't  understand this either.
>
> 1) all text in calligra is unicode
> 2) we have a dialog that allows you to enter specific charactes from any
> unicode range
> 3) yes it is true that the font used to show the text has to support the
> script. But a few free unicode fonts do exist already
>
> On Saturday 02 July 2016 15:13:03 Huxshathra Theudanaz wrote:
> > A distinction between two types of input, a "type mode" and an "unicode
> > mode" in all Calligra applications. In "unicode mode," there should be
> two
> > boxes, one that asks to "choose unicodfoe range" and the other that asks
> to
> > "choose unicode font." Users should select an unicode range, such as
> Greek
> > or Cyrillic, and then choose from a number of unicode fonts, which should
> > come with Calligra, that support that range.
> >
> > "Type mode" and "unicode mode" are different even now. If someone wants
> to
> > type in non-Western European characters, they usually type in "type mode"
> > using fonts they buy. Another option is to type in an unicode font such
> as
> > Arial Unicode MS, and the other unicode fonts are obscure. As one plus,
> > "unicode mode" of input will allow these typists to type in their
> language
> > or script without having at buy extra fonts.
> >
> > Plus word processors and email clients and apps usually do distinguish
> > between "type" and "unicode." This feature will fully allow someone to
> > type, create, and share documents in unicode.
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

How to number components of Calligra 3

[Jaroslaw Staniek]

How to number components of Calligra 3? I mean apps and libs.

In the "state of release and release plan" we're discussing whether to
release together, how "much" together, and what are the challenges.
(I shared some facts regarding Kexi, understanding the topic may seem
a minor one compared to porting statuses and so on)

There's the thing of unbalanced development speed within Calligra. To
be honest I find it a nature of software suites (not just office
suites). For example there were many releases of MS Office where some
apps received cosmetic changes and some other apps more than cosmetic.

The inequality would be sooner or later visible again for Kexi with
then a major redesign of its visible cover/UX gets released.
When that happens? Using the traditional numbering maybe 3.1 or 3.2.
2.0 was a big leap because of switching to Qt 5, and here is another
leap. That's the problem for someone who would rather see the change
causing the bump to 4.0. But then why 3.0 so closely to 4.0 in time?
These may be the natural questions among users.

While we want a clear and pretty standard versioning scheme, changes
like these happen and the traditional x.y.z scheme can look less
natural and makes life easier mostly for packagers. How to handle the
versions is still open question. So far I am looking at possibility of
date-based versioning or frequent major version numbering changes. I
think we discussed some of that before.

Some reasoning again. More often than not we have an X.0 version that
is much different than X.1 version. Then there are X.2 versions and so
on that introduce little changes in some apps and dramatic changes in
other apps. In case of the latter apps X+1 release would make sense
already but other apps receive just some bugfixes or sometimes
nothing. Date-based versioning is one approach that would not
emphasize any milestones, it would move us (or those of us that are
interested) effectively closer to rolling releases like the Chromium
project has or frequent number updates like those of Firefox.

With a marketing hat on I'd say how that would work from "customer's"
perspective. Apps would have own version management[1]. And Calligra
as a brand would have own central number that's managed separately as
a part of the product name. For example how about it would be "3" now
and never 3.1 and so on. Thoughts?

[1] PS: 4 or more libraries that split out of calligra.git repo
already have that, officially or will have to have separate versioning
once binary
compatibility comes to the table.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

state of release and release plan

[Jaroslaw Staniek]

On 2 July 2016 at 08:17, Camilla Boemann  wrote:
>
> Hi
>
> I think it's time we get a release out. We are stuck with not much work going
> on so inspired by Dag's return let's do a push to get ready.
>
> I think we should cut down on the number of applications so we have something
> manageble left. It's tough but the alternative is that Calligra dies
> completely. And nothing prevents us from bringing apps back  later.
>
> So my question is: What is missing for us to have a release. I am not talking
> about all the nice to have features and bug fixes. I am asking what would
> create huge problems for our users if we release.
>
> Let's get things listed. I'll start:
>
>
> Words: Nothing blocking
>
> Stage: Nothing I'm aware of
>
> Sheets: ???
>
> Plan: the locale thing? how much would a quick fix take or should we just
> exclude Plan from first release?
>
> Karbon: let's exclude from first release
>
> Flow: let's exclude from first release
>
> Kexi: are they even a part of the release schedule anymore

In my personal opinion: yes! I see this as our strength.

Anyone contributing/interested in Kexi, please share your thoughts.

As probably mentioned before, separate repositories can but often
should *not* be a reason for splitting the development efforts and
releases. In case of Kexi its the split to 4 repositories, each with
code functioning at another level of the overall architecture.
Most logically, separate tarballs.

One thing to think about is that Kexi is more or less close to a
dramatic change on the UX level [1]. Currently it's like 136 commits
away from kexi.git master. I wouldn't like to see this change causing
delays of the release - first of Kexi, then Calligra.

So something more like current master kexi.git (plus some more last
minute fixes) would be the first released version "3", not the new UX.

The fact that new UX would differ largely, brings questions about
versioning - I would cover this in another thread if you don't mind.

[1] https://blogs.kde.org/2016/06/01/kexi-3

>
> Braindump: let's drop it completely
>
> Common stuff: ???
>
> please fill in
>
> and let's get ready for a release in a month or so ? We need to set a short
> deadline to keep motivation high
>
> best regards
> Camilla
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel



--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Introduction of a "type mode" and an "unicode mode" of input

[Camilla Boemann]

Hi

I don't  understand this either.

1) all text in calligra is unicode
2) we have a dialog that allows you to enter specific charactes from any 
unicode range
3) yes it is true that the font used to show the text has to support the 
script. But a few free unicode fonts do exist already

On Saturday 02 July 2016 15:13:03 Huxshathra Theudanaz wrote:
> A distinction between two types of input, a "type mode" and an "unicode
> mode" in all Calligra applications. In "unicode mode," there should be two
> boxes, one that asks to "choose unicodfoe range" and the other that asks to
> "choose unicode font." Users should select an unicode range, such as Greek
> or Cyrillic, and then choose from a number of unicode fonts, which should
> come with Calligra, that support that range.
> 
> "Type mode" and "unicode mode" are different even now. If someone wants to
> type in non-Western European characters, they usually type in "type mode"
> using fonts they buy. Another option is to type in an unicode font such as
> Arial Unicode MS, and the other unicode fonts are obscure. As one plus,
> "unicode mode" of input will allow these typists to type in their language
> or script without having at buy extra fonts.
> 
> Plus word processors and email clients and apps usually do distinguish
> between "type" and "unicode." This feature will fully allow someone to
> type, create, and share documents in unicode.

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Introduction of a "type mode" and an "unicode mode" of input

[Jaroslaw Staniek]

On 2 July 2016 at 23:01,
​​
​​
Huxshathra Theudanaz  wrote:

> Let's use my actual name now. I put that name together. Huxshathra is an
> old Iranian name, and Theudanaz is old Germanic for Teuton.
>
> I guess you guys understand.
>
> I really want this feature to be implemented.
>

​Hi ​Huxshathra. I don't fully understand the feature maybe because my
alphabet is rather Latin-based. But isn't what you mention is a new input
method/IME? If so, as such place for its implementation isn't at Calligra
level but at a computer operating system's level, even above Qt itself. So
it can consistently serve for all applications. Including LibreOffice
(mentioning it because I remember you've sent similar email to the LO list
too).

Another matter is clarification, do you want/plan to implement this method?
 ​

>
> On Sat, Jul 2, 2016 at 3:58 PM, Huxshathra Theudanaz  > wrote:
>
>> This will be a novel feature. Let's fully utilize unicode.
>>
>> On Sat, Jul 2, 2016 at 3:13 PM, Huxshathra Theudanaz <
>> huxshat...@gmail.com> wrote:
>>
>>> A distinction between two types of input, a "type mode" and an "unicode
>>> mode" in all Calligra applications. In "unicode mode," there should be two
>>> boxes, one that asks to "choose unicodfoe range" and the other that asks to
>>> "choose unicode font." Users should select an unicode range, such as Greek
>>> or Cyrillic, and then choose from a number of unicode fonts, which should
>>> come with Calligra, that support that range.
>>>
>>> "Type mode" and "unicode mode" are different even now. If someone wants
>>> to type in non-Western European characters, they usually type in "type
>>> mode" using fonts they buy. Another option is to type in an unicode font
>>> such as Arial Unicode MS, and the other unicode fonts are obscure. As one
>>> plus, "unicode mode" of input will allow these typists to type in their
>>> language or script without having at buy extra fonts.
>>>
>>> Plus word processors and email clients and apps usually do distinguish
>>> between "type" and "unicode." This feature will fully allow someone to
>>> type, create, and share documents in unicode.
>>>
>>
>>
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>


-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Introduction of a "type mode" and an "unicode mode" of input

[Huxshathra Theudanaz]

Let's use my actual name now. I put that name together. Huxshathra is an
old Iranian name, and Theudanaz is old Germanic for Teuton.

I guess you guys understand.

I really want this feature to be implemented.

On Sat, Jul 2, 2016 at 3:58 PM, Huxshathra Theudanaz 
wrote:

> This will be a novel feature. Let's fully utilize unicode.
>
> On Sat, Jul 2, 2016 at 3:13 PM, Huxshathra Theudanaz  > wrote:
>
>> A distinction between two types of input, a "type mode" and an "unicode
>> mode" in all Calligra applications. In "unicode mode," there should be two
>> boxes, one that asks to "choose unicodfoe range" and the other that asks to
>> "choose unicode font." Users should select an unicode range, such as Greek
>> or Cyrillic, and then choose from a number of unicode fonts, which should
>> come with Calligra, that support that range.
>>
>> "Type mode" and "unicode mode" are different even now. If someone wants
>> to type in non-Western European characters, they usually type in "type
>> mode" using fonts they buy. Another option is to type in an unicode font
>> such as Arial Unicode MS, and the other unicode fonts are obscure. As one
>> plus, "unicode mode" of input will allow these typists to type in their
>> language or script without having at buy extra fonts.
>>
>> Plus word processors and email clients and apps usually do distinguish
>> between "type" and "unicode." This feature will fully allow someone to
>> type, create, and share documents in unicode.
>>
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Introduction of a "type mode" and an "unicode mode" of input

[Huxshathra Theudanaz]

This will be a novel feature. Let's fully utilize unicode.

On Sat, Jul 2, 2016 at 3:13 PM, Huxshathra Theudanaz 
wrote:

> A distinction between two types of input, a "type mode" and an "unicode
> mode" in all Calligra applications. In "unicode mode," there should be two
> boxes, one that asks to "choose unicodfoe range" and the other that asks to
> "choose unicode font." Users should select an unicode range, such as Greek
> or Cyrillic, and then choose from a number of unicode fonts, which should
> come with Calligra, that support that range.
>
> "Type mode" and "unicode mode" are different even now. If someone wants to
> type in non-Western European characters, they usually type in "type mode"
> using fonts they buy. Another option is to type in an unicode font such as
> Arial Unicode MS, and the other unicode fonts are obscure. As one plus,
> "unicode mode" of input will allow these typists to type in their language
> or script without having at buy extra fonts.
>
> Plus word processors and email clients and apps usually do distinguish
> between "type" and "unicode." This feature will fully allow someone to
> type, create, and share documents in unicode.
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Introduction of a "type mode" and an "unicode mode" of input

[Huxshathra Theudanaz]

A distinction between two types of input, a "type mode" and an "unicode
mode" in all Calligra applications. In "unicode mode," there should be two
boxes, one that asks to "choose unicodfoe range" and the other that asks to
"choose unicode font." Users should select an unicode range, such as Greek
or Cyrillic, and then choose from a number of unicode fonts, which should
come with Calligra, that support that range.

"Type mode" and "unicode mode" are different even now. If someone wants to
type in non-Western European characters, they usually type in "type mode"
using fonts they buy. Another option is to type in an unicode font such as
Arial Unicode MS, and the other unicode fonts are obscure. As one plus,
"unicode mode" of input will allow these typists to type in their language
or script without having at buy extra fonts.

Plus word processors and email clients and apps usually do distinguish
between "type" and "unicode." This feature will fully allow someone to
type, create, and share documents in unicode.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Contributing again

[Dag]

Hi, Friedrich.

Friedrich W. H. Kossebau skrev den 2016-07-01 13:20:

Hi Dag,

happy to see you back and giving Plan (and hopefully more) some needed 
love.

Thanks.


When no-one had been found to take over maintenance, I felt Plan was 
some too
good software to just wipe it, so took it as some playground and had 
done some
what I considered "cleaning" and also tried to do the port to Qt5/KF5 
for it.
A lot of cleaning is very much needed, indeed. I will focus on the 
release for know but I have a few things I have thought about for some 
time we should maybe discuss a bit before you put too much effort into 
it.


So far I only roughly reached that porting goal. While everything 
builds and

works to some initial degree, there is at least one big issue:
during the port from KLocale (which is deprecated and in 
kdelibs4support) to
Qt5's QDateTime with built-in timezone support I very possibly missed 
some
scenarios and have broken something. At least the unit tests when run 
for
timezones closer to the daybreak (e.g. Canada) begin to fail, where 
they work
fine in European timezones. Also do the schedulers not return the same 
results

as in Plan 2.9 IIRC. Had not yet found the time to tackle that.
Intriging behaviour, haven't looked at it yet, but as said in my other 
post maybe using time_t in place of KDateTime could be a solution.


Then the support for currencies from KLocale is not (yet) covered by 
Qt5, an

Shouldn't be a problem, see my other post.
issue other projects like KMyMoney also face. No solution for that one 
besides
keeping use of KLocale. Just has the disadvantage that there is no 
systemwide
way to configure currency settings, as Plasma Systemsettings only 
supports
what is exposed in Qt. So default currency settings can be only taken 
from the

installed KLocale data. Not sure what to do here.
Next to that there are some crashes due to libKGantt, but seems you 
already

investigated there and fixed first (or all?), great :)

Have not looked at KGantt yet, the fixes where for KChart.


Am Freitag, 1. Juli 2016, 11:10:03 CEST schrieb Dag:

Thanks, both.
Sure is glad you are still around, tackling words would be a bit
daunting ;)

I ran the tests in libs and got a couple of errors, e.g:

FAIL!  : TestXmlReader::testRootError() Compared values are not the 
same

Actual   (errorMsg): "Ekstra
indhold sidst i dokumentet."
Expected (QString("Extra content at end of document.")): "Extra
content at end of document."

I assume this is ok, just the returned errormsg is localized.
But, if I run in C locale, could this hide other problems?
I saw something in the git log about localized values in xml files.


Oh, interesting, I never hit that one, perhaps I am missing some Qt
translation catalogs in my install (and KDE CI as well).
This test should rather see fixing IMHO. Running in C locale might very 
much
hide other problems, actually at least in Sheets & Plan we currently 
have some

tests failing due to locale problems.


and I get:
QFATAL : TestColorConversionSystem::testConnections() Test function
timed out

Is this real, or can it be that my system is missing something?


Timeout is real, yes. No idea yet what to do with too long running 
tests in

general (also an issue in Marble, Krita, etc.).
I tried to increase ctest --timeout to 500 seconds but that didn't make 
any difference so either its a different timeout, or its a bug in ctest.

Hmmm, maybe there is a way to send an "alive" signal to ctest?


I was to point to 
https://build.kde.org/view/Calligra/job/calligra%20master
%20kf5-qt5/PLATFORM=Linux,compiler=gcc/ for some reference when it 
comes to
failing tests (in Canadian/US timezone/locale) but these very minutes 
that is

done, hopefully back when you try the link.
(last build was reported by CI as failed due to kreport build product 
not
being updated to latest kproperty, because CI does not track 
inter-project

dependencies on builds yet)

WRT review policy I agree with Camilla, review only needed for common 
areas.
For Plan, even while I have committed a lot there in the recent months, 
I yet
have no complete picture of all code, so I bow to you here and will be 
happy
to see your commits going straight in and learn from them, while myself 
will
now have any Plan commits of mine passed by your eyes first (none 
planned the

next days though).

I personally would be happy to see Plan being brought into a working 
state
again, so it can be part of the 3.0 release. By the questions on the 
forums
and bug reports I saw there are still some people interested in 
something like

it. Not everyone is sold to doing planning with Web interfaces :)

Cheers
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org

Re: state of release and release plan

[Camilla Boemann]

Looking at that I'd say only time and currency are real blockers - the others 
are lost functionality but nothing that produces wrong output

RDF support is lost in words, but that shouldn't stop the release

On Saturday 02 July 2016 20:37:17 Dag wrote:
> Preliminary input for Plan. Note that I have not even open all views
> much less tried much functionality, so there may be (a lot) more...
> Also, I'm on vacation 2 last weeks of july and 3. week of august, so
> expecting to be release ready in 1 month would be a bit optimistic ;)
> That said, this is what I know of now:
> 
> Locale/datetime: This could be a difficult problem. A possible solution
> could be to use time_t internally/for calculations etc and convert to
> QDateTime for ui.
> 
> Locale/currency: Should not be a problem, just needs a way to set the
> currency to use for a project so it does not follow the users locale.
> 
> Kross/python: Scripting is used for some functionallity so python
> support is needed. (or else convert to javascript)
> 
> Reports/KReport:
> Scripting is used for getting data from Project and ScheduleManager.
> Alternative to fix KReport is to implement a different way to get this
> info in Plan.
> 
> Report items Chart and Web has not afaics been ported yet.
> 
> Expects to know more on monday,
> Dag
> 
> Camilla Boemann skrev den 2016-07-02 08:17:
> > Hi
> > 
> > I think it's time we get a release out. We are stuck with not much work
> > going
> > on so inspired by Dag's return let's do a push to get ready.
> > 
> > I think we should cut down on the number of applications so we have
> > something
> > manageble left. It's tough but the alternative is that Calligra dies
> > completely. And nothing prevents us from bringing apps back  later.
> > 
> > So my question is: What is missing for us to have a release. I am not
> > talking
> > about all the nice to have features and bug fixes. I am asking what
> > would
> > create huge problems for our users if we release.
> > 
> > Let's get things listed. I'll start:
> > 
> > 
> > Words: Nothing blocking
> > 
> > Stage: Nothing I'm aware of
> > 
> > Sheets: ???
> > 
> > Plan: the locale thing? how much would a quick fix take or should we
> > just
> > exclude Plan from first release?
> > 
> > Karbon: let's exclude from first release
> > 
> > Flow: let's exclude from first release
> > 
> > Kexi: are they even a part of the release schedule anymore
> > 
> > Braindump: let's drop it completely
> > 
> > 
> > Common stuff: ???
> > 
> > please fill in
> > 
> > and let's get ready for a release in a month or so ? We need to set a
> > short
> > deadline to keep motivation high
> > 
> > best regards
> > Camilla
> > ___
> > calligra-devel mailing list
> > calligra-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/calligra-devel
> 
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: state of release and release plan

[Dag]

Preliminary input for Plan. Note that I have not even open all views 
much less tried much functionality, so there may be (a lot) more...
Also, I'm on vacation 2 last weeks of july and 3. week of august, so 
expecting to be release ready in 1 month would be a bit optimistic ;)

That said, this is what I know of now:

Locale/datetime: This could be a difficult problem. A possible solution 
could be to use time_t internally/for calculations etc and convert to 
QDateTime for ui.


Locale/currency: Should not be a problem, just needs a way to set the 
currency to use for a project so it does not follow the users locale.


Kross/python: Scripting is used for some functionallity so python 
support is needed. (or else convert to javascript)


Reports/KReport:
Scripting is used for getting data from Project and ScheduleManager. 
Alternative to fix KReport is to implement a different way to get this 
info in Plan.


Report items Chart and Web has not afaics been ported yet.

Expects to know more on monday,
Dag

Camilla Boemann skrev den 2016-07-02 08:17:

Hi

I think it's time we get a release out. We are stuck with not much work 
going

on so inspired by Dag's return let's do a push to get ready.

I think we should cut down on the number of applications so we have 
something

manageble left. It's tough but the alternative is that Calligra dies
completely. And nothing prevents us from bringing apps back  later.

So my question is: What is missing for us to have a release. I am not 
talking
about all the nice to have features and bug fixes. I am asking what 
would

create huge problems for our users if we release.

Let's get things listed. I'll start:


Words: Nothing blocking

Stage: Nothing I'm aware of

Sheets: ???

Plan: the locale thing? how much would a quick fix take or should we 
just

exclude Plan from first release?

Karbon: let's exclude from first release

Flow: let's exclude from first release

Kexi: are they even a part of the release schedule anymore

Braindump: let's drop it completely


Common stuff: ???

please fill in

and let's get ready for a release in a month or so ? We need to set a 
short

deadline to keep motivation high

best regards
Camilla
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Jenkins-kde-ci: calligra master kf5-qt5 » Linux,gcc - Build # 52 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/52/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 02 Jul 2016 11:36:05 +
Build duration: 45 min

CHANGE SET
Revision 9f1ebd6d901a818a46cdff3a4a3432ac85034436 by Friedrich W. H. Kossebau: 
(Make TestXmlReader/TestXmlReaderWithoutSpaces handle translated error)
  change: edit libs/odf/tests/TestXmlReader.cpp
  change: edit libs/odf/tests/TestXmlReaderWithoutSpaces.cpp


JUNIT RESULTS

Name: (root) Failed: 7 test(s), Passed: 152 test(s), Skipped: 0 test(s), Total: 
159 test(s)Failed: TestSuite.libs-pigment-TestColorConversionSystemFailed: 
TestSuite.plan-models-WorkPackageProxyModelTesterFailed: 
TestSuite.plan-schedulers-rcps-RCPSTesterFailed: 
TestSuite.plan-schedulers-tj-SchedulerTesterFailed: 
TestSuite.sheets-DatetimeFunctionsFailed: 
TestSuite.sheets-ValueConverterFailed: TestSuite.sheets-ValueParser

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 155/189 (82%)FILES 1338/2963 (45%)CLASSES 1338/2963 (45%)LINE 
96619/319895 (30%)CONDITIONAL 62868/362739 (17%)

By packages
  
braindump.braindumpcore
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/134 (0%)CONDITIONAL 0/98 
(0%)
braindump.plugins.stateshape
FILES 4/14 (29%)CLASSES 4/14 (29%)LINE 24/280 (9%)CONDITIONAL 
3/140 (2%)
braindump.plugins.webshape
FILES 4/9 (44%)CLASSES 4/9 (44%)LINE 22/295 (7%)CONDITIONAL 
1/114 (1%)
braindump.src
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/3 (0%)CONDITIONAL 0/0 
(100%)
devtools.rng2cpp
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 600/693 (87%)CONDITIONAL 
596/814 (73%)
filters.libmso
FILES 10/12 (83%)CLASSES 10/12 (83%)LINE 880/7716 
(11%)CONDITIONAL 2166/19949 (11%)
filters.libmso.generated
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 4193/12624 
(33%)CONDITIONAL 4190/24261 (17%)
filters.libmsooxml
FILES 2/35 (6%)CLASSES 2/35 (6%)LINE 3/8009 (0%)CONDITIONAL 
2/25193 (0%)
filters.libmsooxml.generated
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/743 (0%)CONDITIONAL 0/3336 
(0%)
filters.libodf2
FILES 6/29 (21%)CLASSES 6/29 (21%)LINE 97/1606 (6%)CONDITIONAL 
82/2186 (4%)
filters.libodf2.chart
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/582 (0%)CONDITIONAL 0/1365 
(0%)
filters.sheets.excel.sidewinder
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 654/685 (95%)CONDITIONAL 
1919/3504 (55%)
filters.sheets.xlsx
FILES 4/5 (80%)CLASSES 4/5 (80%)LINE 111/281 (40%)CONDITIONAL 
67/478 (14%)
filters.stage.powerpoint
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 1651/2710 
(61%)CONDITIONAL 2004/6154 (33%)
filters.stage.powerpoint.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 56/58 (97%)CONDITIONAL 
94/198 (47%)
interfaces
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 54/61 (89%)CONDITIONAL 
36/73 (49%)
libs.basicflakes.plugin
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 23/31 (74%)CONDITIONAL 
1/8 (13%)
libs.basicflakes.tools
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/819 (0%)CONDITIONAL 0/413 
(0%)
libs.flake
FILES 111/180 (62%)CLASSES 111/180 (62%)LINE 5273/13797 
(38%)CONDITIONAL 2895/9878 (29%)
libs.flake.commands
FILES 19/49 (39%)CLASSES 19/49 (39%)LINE 805/2153 
(37%)CONDITIONAL 410/1380 (30%)
libs.flake.svg
FILES 1/20 (5%)CLASSES 1/20 (5%)LINE 8/2456 (0%)CONDITIONAL 
1/1698 (0%)
libs.flake.tests
FILES 49/49 (100%)CLASSES 49/49 (100%)LINE 3740/3773 
(99%)CONDITIONAL 1718/3394 (51%)
libs.flake.tools
FILES 9/43 (21%)CLASSES 9/43 (21%)LINE 155/1625 
(10%)CONDITIONAL 45/952 (5%)
libs.kross
FILES 0/10 (0%)CLASSES 0/10 (0%)LINE 0/730 (0%)CONDITIONAL 
0/496 (0%)
libs.kundo2
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 209/732 (29%)CONDITIONAL 
70/410 (17%)
libs.main
FILES 28/75 (37%)CLASSES 28/75 (37%)LINE 734/7303 
(10%)CONDITIONAL 799/17389 (5%)
libs.main.config
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/218 (0%)CONDITIONAL 0/478 
(0%)
libs.main.gemini
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/2 (0%)CONDITIONAL 0/0 
(100%)
libs.main.tests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 258/271 (95%)CONDITIONAL 
139/236 (59%)
libs.odf
FILES 39/46 (85%)CLASSES 39/46 (85%)LINE 2007/5615 
(36%)CONDITIONAL 1273/4311 (30%)
libs.odf.tests
FILES 17/17 (100%)CLASSES 17/17 (100%)LINE 4860/5100 
(95%)CONDITIONAL 3520/7158 (49%)
libs.odf.writeodf
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 77/106 (73%)CONDITIONAL 
29/59 (49%)

[Differential] [Closed] D2058: Make TestXmlReader/TestXmlReaderWithoutSpaces handle translated error messages

[kossebau (Friedrich W. H. Kossebau)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rCALLIGRA9f1ebd6d901a: Make 
TestXmlReader/TestXmlReaderWithoutSpaces handle translated error messages 
(authored by kossebau).

REPOSITORY
  rCALLIGRA Calligra

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2058?vs=4887=4896

REVISION DETAIL
  https://phabricator.kde.org/D2058

AFFECTED FILES
  libs/odf/tests/TestXmlReader.cpp
  libs/odf/tests/TestXmlReaderWithoutSpaces.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, Calligra-Devel-list, boemann
Cc: boemann, staniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: state of release and release plan

[Tomas Mecir]

No big blockers on Sheets. There's a lot of "would be nice"s and "this
should work better"s, but all apps have that, I imagine.

2016-07-02 8:17 GMT+02:00 Camilla Boemann :
> Hi
>
> I think it's time we get a release out. We are stuck with not much work going
> on so inspired by Dag's return let's do a push to get ready.
>
> I think we should cut down on the number of applications so we have something
> manageble left. It's tough but the alternative is that Calligra dies
> completely. And nothing prevents us from bringing apps back  later.
>
> So my question is: What is missing for us to have a release. I am not talking
> about all the nice to have features and bug fixes. I am asking what would
> create huge problems for our users if we release.
>
> Let's get things listed. I'll start:
>
>
> Words: Nothing blocking
>
> Stage: Nothing I'm aware of
>
> Sheets: ???
>
> Plan: the locale thing? how much would a quick fix take or should we just
> exclude Plan from first release?
>
> Karbon: let's exclude from first release
>
> Flow: let's exclude from first release
>
> Kexi: are they even a part of the release schedule anymore
>
> Braindump: let's drop it completely
>
>
> Common stuff: ???
>
> please fill in
>
> and let's get ready for a release in a month or so ? We need to set a short
> deadline to keep motivation high
>
> best regards
> Camilla
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

state of release and release plan

[Camilla Boemann]

Hi

I think it's time we get a release out. We are stuck with not much work going 
on so inspired by Dag's return let's do a push to get ready.

I think we should cut down on the number of applications so we have something 
manageble left. It's tough but the alternative is that Calligra dies 
completely. And nothing prevents us from bringing apps back  later.

So my question is: What is missing for us to have a release. I am not talking 
about all the nice to have features and bug fixes. I am asking what would 
create huge problems for our users if we release.

Let's get things listed. I'll start:


Words: Nothing blocking

Stage: Nothing I'm aware of

Sheets: ???

Plan: the locale thing? how much would a quick fix take or should we just 
exclude Plan from first release?

Karbon: let's exclude from first release

Flow: let's exclude from first release

Kexi: are they even a part of the release schedule anymore

Braindump: let's drop it completely


Common stuff: ???

please fill in

and let's get ready for a release in a month or so ? We need to set a short 
deadline to keep motivation high

best regards
Camilla
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

[Differential] [Accepted] D2058: Make TestXmlReader/TestXmlReaderWithoutSpaces handle translated error messages

[boemann (Camilla Boemann)]

boemann accepted this revision.
boemann added a reviewer: boemann.
boemann added a comment.
This revision is now accepted and ready to land.


  Was my idea on how to fix too so i agree

REPOSITORY
  rCALLIGRA Calligra

BRANCH
  fixTestXmlReaderTestingTranslatedErrorMessages

REVISION DETAIL
  https://phabricator.kde.org/D2058

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, Calligra-Devel-list, boemann
Cc: boemann, staniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel