Re: Some buttons on Maths palette don't work!

[Oliver Frolovs]

If I had to take a wild guess, I would suppose it’s the font rather than SIP – 
after all *some* of the buttons do work, as I had tried to demonstrate in the 
video. For example, the Greek letters – the first two rows (and if I remember 
correctly a few last rows) don’t work, while the rows in the middle do work.

I’ve seen the same problem reported in one of the LyX forums (they had a 
Youtube video attached) but I cannot find it now.

It’s not a show stopper as I can still open the various sub palettes manually 
and use them, it’s just they take lots of space on the screen. Is there 
anything I can do to assist with the debugging of this problem?

Best,
Ollie

> On 7 Oct 2015, at 20:45, Stephan Witt  wrote:
> 
> Am 06.10.2015 um 23:32 schrieb Oliver Frolovs 
> :
> 
>> Hello everyone,
>> 
>> I am testing LyX suitability for my thesis write-up, 
>> and I've come across an odd problem: 
>> the buttons in submenus on the maths toolbar
>> are _mostly_ unclickable. By that I mean 
>> that the first row of the buttons in any given 
>> submenu on that palette does not work. 
>> It's hard to explain in words, so I have
>> recorded a short video showing what works 
>> and what does not: https://vimeo.com/141471729
>> 
>> I'm running LyX Version 2.1.4 (24 July 2015) 
>> on OS X 10.11 (El Capitan).
>> 
>> Please let me know if I am missing something 
>> obvious here. I've read the Tutorial and
>> if I understood it correctly, all of these buttons 
>> should work in maths mode (and some of them do).
> 
> Hi Ollie,
> 
> unfortunately I'm unable to test LyX on El Capitan, ATM.
> 
> AFAIK, there are two changes with the potential to affect LyX's
> functionality:
> 
> 1. The new security feature SIP
> 
> This forbids the existence of non-Apple files at system locations.
> So, the links to the LaTeX-software utilities will not be allowed
> anymore and removed if already present on upgrade. LyX's PATH 
> settings needs to be changed to point it to the (non-standard)
> place where it's installed physically.
> 
> 2. The new system font San Francisco
> 
> This changes the metrics of the dialogs. I don't know how it looks
> and if it is possible to cause the effect you describe.
> 
> Regards,
> Stephan

Re: Size of box insets

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> This looks like a good solution.
> 
> Now that I think about it, what about fixed-width tabular cells ? Do they 
> have the same problem ?

To me it's the same as in ERT, i.e. I can easily imagine very tiny content like 
one character so you
don't want to set button size minimum (whatever button means in the table).

Attached is updated patch.
Pavel
diff --git a/src/insets/InsetCollapsable.cpp b/src/insets/InsetCollapsable.cpp
index 623cebb..bdc2f4f 100644
--- a/src/insets/InsetCollapsable.cpp
+++ b/src/insets/InsetCollapsable.cpp
@@ -213,6 +213,11 @@ void InsetCollapsable::metrics(MetricsInfo & mi, Dimension & dim) const
 	case TopButton:
 	case LeftButton:
 	case ButtonOnly:
+		if (hasFixedWidth()){
+			int mindim=button_dim.x2-button_dim.x1;
+			if (mi.base.textwidth

Re: Size of box insets

[Jean-Marc Lasgouttes]

Le 07/10/2015 10:10, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

This looks like a good solution.

Now that I think about it, what about fixed-width tabular cells ? Do they have 
the same problem ?


To me it's the same as in ERT, i.e. I can easily imagine very tiny content like 
one character so you
don't want to set button size minimum (whatever button means in the table).

Attached is updated patch.


Looks good to me, but spacing is, well, you know...

And you can constify mindim for the beauty of it.

JMarc

Re: Release manager for LyX 2.2

[Jean-Marc Lasgouttes]

Le 07/10/2015 11:04, Pavel Sanda a écrit :

Hi all,

it is very clear that we need to move forward with the release process.

After the discussion with the former and current managers we agreed that Scott
Kostyshak has our trust for the role of release manager of 2.2. He has good
understanding of the code and is constantly around to help with the development
process which makes him a perfect candidate.

He tentatively agreed to accept such responsibility.

If someone has objections to this proposal please speak now or never :)
Otherwise I wish good luck to our new release manager!


That is very good news. Scott, welcome to your new role.

Besides checking everything that may go wrong, remember that the second 
most important part of the job is to say "no"! And that's not the 
easiest part.


JMarc

Re: UTF-8 in string literals and translation strings in particular

[Jean-Marc Lasgouttes]

Le 07/10/2015 01:23, Pavel Sanda a écrit :

Le 06/10/2015 21:01, Pavel Sanda a écrit :
I think you might be mixing issues. One thing is allowing to have
UTF-8 string literals especially in translations, another one is
deciding that we now use ? instead of ... in the interface to be
consistent with Qt.


To clarify, I'm not against having ellipsis in the menu per se by whatever
mechanism you use to pass it to Qt routines. What I am not way too happy is
increasing % of utf8-based source code itself and following translations.


That would be trivial easy to implement for menus indeed. Or even for 
dialogs, if we put the code in _().


JMarc

Release manager for LyX 2.2

[Pavel Sanda]

Hi all,

it is very clear that we need to move forward with the release process.

After the discussion with the former and current managers we agreed that Scott
Kostyshak has our trust for the role of release manager of 2.2. He has good
understanding of the code and is constantly around to help with the development
process which makes him a perfect candidate.

He tentatively agreed to accept such responsibility.

If someone has objections to this proposal please speak now or never :)
Otherwise I wish good luck to our new release manager!

Pavel

Re: UTF-8 in string literals and translation strings in particular

[Jean-Marc Lasgouttes]

Le 06/10/2015 21:43, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

Well, actually I am not sure that we use the same ellipsis as in English.


You mean as a translator I need to find French version of ellipsis?


I am not sure that it exists.

JMarc

Re: UTF-8 in string literals and translation strings in particular

[Jean-Marc Lasgouttes]

Le 06/10/2015 22:17, Guillaume Munch a écrit :

I think you might be mixing issues. One thing is allowing to have UTF-8
string literals especially in translations, another one is deciding that
we now use … instead of ... in the interface to be consistent with Qt.


What would be worse than using ... in the UI would be to use a random 
mix of ... and … (look Ma, I managed to type it with my compose key!) in 
the UI. By doing this change, we put more pressure on our translators to 
do thing right.


An alternative would be the attached hack.

JMarc
>From c48e487a7c1ba98061d55d6b2d0f2b2a0a219986 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Wed, 7 Oct 2015 10:34:06 +0200
Subject: [PATCH] Transform ... to proper ellipsis in translations

---
 src/support/Messages.cpp |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/support/Messages.cpp b/src/support/Messages.cpp
index da1c3cc..177436f 100644
--- a/src/support/Messages.cpp
+++ b/src/support/Messages.cpp
@@ -94,6 +94,7 @@
 #endif
 
 using namespace std;
+using namespace lyx::support;
 using boost::uint32_t;
 
 namespace lyx {
@@ -125,6 +126,10 @@ void cleanTranslation(docstring & trans)
 		}
 		break;
 	}
+
+	static docstring const threedots = from_ascii("...");
+	static docstring const ellipsis = docstring(1, 0x2026);
+	trans = subst(trans, threedots, ellipsis);
 }
 
 } // lyx
@@ -132,8 +137,6 @@ void cleanTranslation(docstring & trans)
 
 #ifdef ENABLE_NLS
 
-using namespace lyx::support;
-
 namespace lyx {
 
 std::string Messages::gui_lang_;
-- 
1.7.9.5

Re: UTF-8 in string literals and translation strings in particular

[Jean-Marc Lasgouttes]

Le 06/10/2015 20:52, Guillaume Munch a écrit :

(For proper French usage, you can also input accented upper-case
characters and I am sure that your question marks are preceded by a
space − though I would agree that a thin space would appear as too
formal in e-mails.)


Ha! You do not know who you are talking to. A former PhD student 
complained that because of me, he had become too obsessed with 
orthotypography to be able to concentrate on the contents of what he was 
reading :)


The fact is that, with the patch that I posted a minute ago, I had 
trouble to convince myself that the ... were replaced with …, since the 
difference is quite subtle. Can you really see the difference 
immediately when you use a menu?



I could propose to hack it into the menu code...


Please, no. Would you also hack my changes to
src/frontends/qt4/ui/HSpaceUi.ui into the dialog code?


Well I did write the patch anyway.


(For ellipses though, I find more useful to read … in the source
rather than \u2026.)


Well it would if our mechanism for sending patches to lyx-cvs did 
specify correctly the attachment encoding to utf8. Right now, I just see 
garbage.


JMarc

Re: UTF-8 in string literals and translation strings in particular

[Cyrille Artho]

Unicode characters in some menus (math panel etc.) would indeed look
much better than pixelated bitmaps.


Do you have particular examples in mind? I thought we used svg icons these
days.

In my view, it is better to have a character that looks like the math font
that LyX uses, than a poorly designed unicode character that smells MS Word
from 100 meters. Unless we teach LyX how to use unicode math fonts, but
this is not for today.

JMarc

>
In the math panel on Mac OS X (non-Retina displays), the icons are very 
pixelated. This could be due to the rendering without anti-aliasing but in 
any case most of the icons look very dated due to that.


Examples are the Laplace operator ∇, the inequality signs ≤ ≦ ≮ and the 
root symbols in row 2. Examples that *are* anti-aliases and look better, 
are "a/b" and the parentheses.


Maybe this is again because people wanted to "play safe" for systems 
without a complete Unicode character set.

--
Regards,
Cyrille Artho - http://artho.com/
I love deadlines. I like the whooshing sound they make as they fly by.
-- Douglas Adams

Re: UTF-8 in string literals and translation strings in particular

[Cyrille Artho]

 >
In the math panel on Mac OS X (non-Retina displays), the icons are very
pixelated. This could be due to the rendering without anti-aliasing but in
any case most of the icons look very dated due to that.

Examples are the Laplace operator ∇, the inequality signs ≤ ≦ ≮ and the
root symbols in row 2. Examples that *are* anti-aliases and look better,
are "a/b" and the parentheses.

Maybe this is again because people wanted to "play safe" for systems
without a complete Unicode character set.

>
It's possible to embed characters from a font in an SVG graph; this could 
be used to avoid problems with fonts that do not have all math characters.


I've found some information on this page:

http://www.xml.com/lpt/a/1410

(roughly in the middle of the text). I'm not sure which tools can automate 
this process, though.

--
Regards,
Cyrille Artho - http://artho.com/
For a list of the ways which technology has
failed to improve our quality of life, press 3.
-- Phil Read, on Slashdot

Some buttons on Maths palette don't work!

[John Kennan]

The palette problem on El Capitan doesn't seem to have anything to do 
with SIP -- I disabled it (and reconfigured LyX) and the problem 
remained. This is LyX 2.1.4 (on a Retina machine -- the same LyX on a 
different Retina machine running OS X 10.10.5 doesn't have this 
problem). If there was a test version of 2.2 available for OSX, I could 
try that.


Actually, I can't get any of the Greek symbols by clicking on the palette.

--
John Kennan

Re: UTF-8 in string literals and translation strings in particular

[Cyrille Artho]

Jean-Marc Lasgouttes wrote:

Le 06/10/2015 22:17, Guillaume Munch a écrit :

I think you might be mixing issues. One thing is allowing to have UTF-8
string literals especially in translations, another one is deciding that
we now use … instead of ... in the interface to be consistent with Qt.


What would be worse than using ... in the UI would be to use a random mix
of ... and … (look Ma, I managed to type it with my compose key!) in the
UI. By doing this change, we put more pressure on our translators to do
thing right.

An alternative would be the attached hack.

JMarc


Why not apply a variant of that hack as using "sed" to all the 
language/menu strings in the repository? Of course the changes would have 
to be checked by a human in case one wants to keep "..." in some cases.


I think if we replace all "..." (perhaps in all menus, or also in most/all 
of the manuals), then there will be very few new instances where we need to 
distinguish between "..." and a proper ellipsis.


At least on MacOS, the difference is very clear, the ellipsis is easy to 
get through the character viewer, and text-to-speech software and other 
converters may also work better with proper punctuation (although that's 
pure speculation from my side, I have not tested that).

--
Regards,
Cyrille Artho - http://artho.com/
I love deadlines. I like the whooshing sound they make as they fly by.
-- Douglas Adams

Re: UTF-8 in string literals and translation strings in particular

[Abdelrazak Younes]

On 07/10/2015 10:54, Jean-Marc Lasgouttes wrote:

Le 06/10/2015 22:17, Guillaume Munch a écrit :

I think you might be mixing issues. One thing is allowing to have UTF-8
string literals especially in translations, another one is deciding that
we now use … instead of ... in the interface to be consistent with Qt.


What would be worse than using ... in the UI would be to use a random 
mix of ... and … (look Ma, I managed to type it with my compose key!) 
in the UI. By doing this change, we put more pressure on our 
translators to do thing right.


An alternative would be the attached hack.


No need for any hack: Another alternative that works AFAIR and is 
cleaner IMO, english to english translation works. So, for english or 
french actually, ... can be translated to the ellipsis character.


Abdel.

Re: Release manager for LyX 2.2

[Stephan Witt]

Am 07.10.2015 um 17:19 schrieb Richard Heck :

> On 10/07/2015 05:08 AM, Jean-Marc Lasgouttes wrote:
>> Le 07/10/2015 11:04, Pavel Sanda a écrit :
>>> Hi all,
>>> 
>>> it is very clear that we need to move forward with the release process.
>>> 
>>> After the discussion with the former and current managers we agreed that 
>>> Scott
>>> Kostyshak has our trust for the role of release manager of 2.2. He has good
>>> understanding of the code and is constantly around to help with the 
>>> development
>>> process which makes him a perfect candidate.
>>> 
>>> He tentatively agreed to accept such responsibility.
>>> 
>>> If someone has objections to this proposal please speak now or never :)
>>> Otherwise I wish good luck to our new release manager!
>> 
>> That is very good news. Scott, welcome to your new role.
> 
> Seconded. I am confident you will do a great job, Scott.

Me too. Thank you for taking the responsibility.

Stephan

Re: Release manager for LyX 2.2

[Abdelrazak Younes]

On 07/10/2015 21:35, Stephan Witt wrote:

Am 07.10.2015 um 17:19 schrieb Richard Heck :


On 10/07/2015 05:08 AM, Jean-Marc Lasgouttes wrote:

Le 07/10/2015 11:04, Pavel Sanda a écrit :

Hi all,

it is very clear that we need to move forward with the release process.

After the discussion with the former and current managers we agreed that Scott
Kostyshak has our trust for the role of release manager of 2.2. He has good
understanding of the code and is constantly around to help with the development
process which makes him a perfect candidate.

He tentatively agreed to accept such responsibility.

If someone has objections to this proposal please speak now or never :)
Otherwise I wish good luck to our new release manager!

That is very good news. Scott, welcome to your new role.

Seconded. I am confident you will do a great job, Scott.

Me too. Thank you for taking the responsibility.


And me as well :-)

Cheers,
Abdel.

Re: Some buttons on Maths palette don't work!

[Stephan Witt]

Am 06.10.2015 um 23:32 schrieb Oliver Frolovs 
:

> Hello everyone,
> 
> I am testing LyX suitability for my thesis write-up, 
> and I've come across an odd problem: 
> the buttons in submenus on the maths toolbar
> are _mostly_ unclickable. By that I mean 
> that the first row of the buttons in any given 
> submenu on that palette does not work. 
> It's hard to explain in words, so I have
> recorded a short video showing what works 
> and what does not: https://vimeo.com/141471729
> 
> I'm running LyX Version 2.1.4 (24 July 2015) 
> on OS X 10.11 (El Capitan).
> 
> Please let me know if I am missing something 
> obvious here. I've read the Tutorial and
> if I understood it correctly, all of these buttons 
> should work in maths mode (and some of them do).

Hi Ollie,

unfortunately I'm unable to test LyX on El Capitan, ATM.

AFAIK, there are two changes with the potential to affect LyX's
functionality:

1. The new security feature SIP

This forbids the existence of non-Apple files at system locations.
So, the links to the LaTeX-software utilities will not be allowed
anymore and removed if already present on upgrade. LyX's PATH 
settings needs to be changed to point it to the (non-standard)
place where it's installed physically.

2. The new system font San Francisco

This changes the metrics of the dialogs. I don't know how it looks
and if it is possible to cause the effect you describe.

Regards,
Stephan

Re: UTF-8 in string literals and translation strings in particular

[Jean-Marc Lasgouttes]

Le 07/10/2015 01:10, Cyrille Artho a écrit :

I think for UI guidelines, if Apple and Gnome recommend A, and Microsoft
recommends B, then A is definitely the right way. ;-)


Agreed.


who knows how to get an ellipsis on his/her keyboard?


It's trivial. Character viewer -> Punctuation -> there it is right away.
If you type it often you can look up the keyboard shortcut.


Our translateors are not all geeks. We have to make life easy for them.


Unicode characters in some menus (math panel etc.) would indeed look
much better than pixelated bitmaps.


Do you have particular examples in mind? I thought we used svg icons 
these days.


In my view, it is better to have a character that looks like the math 
font that LyX uses, than a poorly designed unicode character that smells 
MS Word from 100 meters. Unless we teach LyX how to use unicode math 
fonts, but this is not for today.


JMarc

Re: UTF-8 in string literals and translation strings in particular

[Jean-Marc Lasgouttes]

Le 06/10/2015 21:43, Guillaume Munch a écrit :

-LASSERT(static_cast(*c) < 0x80, return l);
-s.push_back(*c);
+if (static_cast(*c) < 0x80)
+s.push_back(*c);
+else
+return s += from_utf8(string(c));




In the meanwhile I understood that probably the precision that you need
is that c is a C string that denotes the suffix of r and string(c)
converts the whole remainder of r into a c++ string, not just the next
char.


I would not describe that code as readable ;) This early return in the 
loop is pretty weird.


OTOH, I am not opposed to extending docstring to understand utf8. At the 
time where it was introduced, it was decided to stick to ASCII because 
there was a big risk of passing latin1 strings. We can probably assume 
that this risk is gone now.


JMarc

Re: Size of box insets

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> but spacing is, well, you know...

Awesome, I know. P

Re: Size of box insets

[Jean-Marc Lasgouttes]

Le 07/10/2015 11:26, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

but spacing is, well, you know...


Awesome, I know. P


Naughty boy. You thought you would get away with it?

JMarc

Re: Release manager for LyX 2.2

[Liviu Andronic]

On Wed, Oct 7, 2015 at 11:08 AM, Jean-Marc Lasgouttes
 wrote:
> Le 07/10/2015 11:04, Pavel Sanda a écrit :
>>
>> Hi all,
>>
>> it is very clear that we need to move forward with the release process.
>>
>> After the discussion with the former and current managers we agreed that
>> Scott
>> Kostyshak has our trust for the role of release manager of 2.2. He has
>> good
>> understanding of the code and is constantly around to help with the
>> development
>> process which makes him a perfect candidate.
>>
>> He tentatively agreed to accept such responsibility.
>>
>> If someone has objections to this proposal please speak now or never :)
>> Otherwise I wish good luck to our new release manager!
>
>
> That is very good news. Scott, welcome to your new role.
>
+1

Liviu


> Besides checking everything that may go wrong, remember that the second most
> important part of the job is to say "no"! And that's not the easiest part.
>
> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Release manager for LyX 2.2

[Kornel Benko]

Am Mittwoch, 7. Oktober 2015 um 11:08:21, schrieb Jean-Marc Lasgouttes 

> Le 07/10/2015 11:04, Pavel Sanda a écrit :
> > Hi all,
> >
> > it is very clear that we need to move forward with the release process.
> >
> > After the discussion with the former and current managers we agreed that 
> > Scott
> > Kostyshak has our trust for the role of release manager of 2.2. He has good
> > understanding of the code and is constantly around to help with the 
> > development
> > process which makes him a perfect candidate.
> >
> > He tentatively agreed to accept such responsibility.
> >
> > If someone has objections to this proposal please speak now or never :)
> > Otherwise I wish good luck to our new release manager!
> 
> That is very good news. Scott, welcome to your new role.
> 
> Besides checking everything that may go wrong, remember that the second 
> most important part of the job is to say "no"! And that's not the 
> easiest part.
> 
> JMarc

+1

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Release manager for LyX 2.2

[Richard Heck]

On 10/07/2015 05:08 AM, Jean-Marc Lasgouttes wrote:

Le 07/10/2015 11:04, Pavel Sanda a écrit :

Hi all,

it is very clear that we need to move forward with the release process.

After the discussion with the former and current managers we agreed 
that Scott
Kostyshak has our trust for the role of release manager of 2.2. He 
has good
understanding of the code and is constantly around to help with the 
development

process which makes him a perfect candidate.

He tentatively agreed to accept such responsibility.

If someone has objections to this proposal please speak now or never :)
Otherwise I wish good luck to our new release manager!


That is very good news. Scott, welcome to your new role.


Seconded. I am confident you will do a great job, Scott.

Richard

RE: #9793: 2.1.4 crashed

[Dick Startz]

I'm sorry. I don't have an earlier version.

-Original Message-
From: LyX Ticket Tracker [mailto:t...@lyx.org]
Sent: Tuesday, October 06, 2015 11:38 PM
To: sta...@ucsb.edu; lasgout...@lyx.org
Subject: Re: #9793: 2.1.4 crashed

#9793: 2.1.4 crashed
-+-
 Reporter:  startz   |   Owner:  lasgouttes
 Type:  defect   |  Status:  new
 Priority:  normal   |   Milestone:
Component:  general  | Version:  2.1.4
 Severity:  normal   |  Resolution:
 Keywords:   |
-+-

Comment (by skostysh):

 Thanks for taking the time to report this startz.

 Do you have a version of the file that you happened to save *just before*
the crash (thus it would be a little different from the .emergency file) ?

--
Ticket URL: 
The LyX Project 
LyX -- The Document Processor

Compiling LyX on Windows with more recent Visual Studio versions

[David Hyde]

Hi there,


I'm interested in compiling LyX on Windows.  I've read through the 
INSTALL.Win32 file and was able to get LyX to compile from source using Visual 
C++ Express 2010, following the instructions in that file.  I'm wondering 
though, is it possible (do people have experience, or know it doesn't work, 
etc.) to compile LyX using a more recent VS version (2013 or even 2015)?  
VS2010 isn't supported very well anymore (it was hard to even find a download 
for VS2010), so being able to compile LyX on Windows using more modern 
toolchains would be very useful.


Thanks for any advice or experiences you may have on this!


David

Re: Size of box insets

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 07/10/2015 11:26, Pavel Sanda a écrit :
>> Jean-Marc Lasgouttes wrote:
>>> but spacing is, well, you know...
>>
>> Awesome, I know. P
>
> Naughty boy. You thought you would get away with it?

Daddy, I promise to be better next time until I forget again :p
P

Re: Release manager for LyX 2.2

[Scott Kostyshak]

On Wed, Oct 07, 2015 at 11:19:32AM -0400, Richard Heck wrote:
> On 10/07/2015 05:08 AM, Jean-Marc Lasgouttes wrote:
> >Le 07/10/2015 11:04, Pavel Sanda a écrit :
> >>Hi all,
> >>
> >>it is very clear that we need to move forward with the release process.
> >>
> >>After the discussion with the former and current managers we agreed that
> >>Scott
> >>Kostyshak has our trust for the role of release manager of 2.2. He has
> >>good
> >>understanding of the code and is constantly around to help with the
> >>development
> >>process which makes him a perfect candidate.
> >>
> >>He tentatively agreed to accept such responsibility.
> >>
> >>If someone has objections to this proposal please speak now or never :)
> >>Otherwise I wish good luck to our new release manager!
> >
> >That is very good news. Scott, welcome to your new role.
> 
> Seconded. I am confident you will do a great job, Scott.

Thank you all for the encouragement. I look forward to the challenge!

Scott