Talk:OggKate - Revision history

Martin.leese: Added attribution

2009-08-24T13:14:25Z

Added attribution

← Older revision		Revision as of 13:14, 24 August 2009
Line 20:		Line 20:
	:::I was asking about Kate supporting all unicode features. (I didn't knew about Unicode having language, country,... mapping.) If you want to tell me that Unicode has a region, language, currency,... mapping on top of a character mapping. Then say it clearly.		:::I was asking about Kate supporting all unicode features. (I didn't knew about Unicode having language, country,... mapping.) If you want to tell me that Unicode has a region, language, currency,... mapping on top of a character mapping. Then say it clearly.

-	:::Reading this page: [http://cldr.unicode.org/]. All the localization stuff are under the name CLDR. CLDR is about the Unicode Common Locale Data Repository. It does a lot more than just language and region mapping.	+	:::Reading this page: [http://cldr.unicode.org/]. All the localization stuff are under the name CLDR. CLDR is about the Unicode Common Locale Data Repository. It does a lot more than just language and region mapping. In fact, the other things are also very useful to have. (e.g. Engineers and the whole scientific community would be very pleased with the number localization.) (Because of the decimal and thousands separator issue: [http://en.wikipedia.org/wiki/Decimal_separator])
-	In fact, the other things are also very useful to have. (e.g. Engineers and the whole scientific community would be very pleased with the number localization.) (Because of the decimal and thousands separator issue: [http://en.wikipedia.org/wiki/Decimal_separator])	+

	:::[[User:Vmol:Vmol]] 31 July 2009		:::[[User:Vmol:Vmol]] 31 July 2009
Line 70:		Line 69:

	What is your opinion about svgfonts?		What is your opinion about svgfonts?
		+
		+	[[User:Vmol:Vmol]] 31 July 2009

	: I have no opinion about svgfonts, as I do not know about them.		: I have no opinion about svgfonts, as I do not know about them.
	: I have proof of concept support for SVG images in Kate, but there are unresolved issues.		: I have proof of concept support for SVG images in Kate, but there are unresolved issues.
	: It'd be nice to have SVG in, and I suppose (but only suppose) SVG fonts would automagically work then. [[User:Ogg.k.ogg.k\|Ogg.k.ogg.k]]		: It'd be nice to have SVG in, and I suppose (but only suppose) SVG fonts would automagically work then. [[User:Ogg.k.ogg.k\|Ogg.k.ogg.k]]

Martin.leese: Added attribution

2009-08-24T13:11:44Z

Added attribution

← Older revision		Revision as of 13:11, 24 August 2009
Line 1:		Line 1:
	== Kate is going to have support for all languages in the world, right ? ==		== Kate is going to have support for all languages in the world, right ? ==
		+
	(This can be useful to make a video where a user can choose the right subtitle language.)		(This can be useful to make a video where a user can choose the right subtitle language.)

Line 8:		Line 9:
	::Right to left now supported (in my local version of xine). Language directionality can be overridden for each data packet from the default given in the headers. [[User:ogg.k.ogg.k]] Thurs Jan 31 13:29 UTC 2008		::Right to left now supported (in my local version of xine). Language directionality can be overridden for each data packet from the default given in the headers. [[User:ogg.k.ogg.k]] Thurs Jan 31 13:29 UTC 2008

-	Be careful to make sure you're using the latest ISO standard (the one with the highest number) about languages.	+	Be careful to make sure you're using the latest ISO standard (the one with the highest number) about languages. Because there are already a few so you could miss and end up using a wrong one. For the rest Kate looks very good ;)
-	Because there are already a few so you could miss and end up using a wrong one.	+
-	For the rest Kate looks very good ;)	+

	:: Well, I am not certain about this - assuming you are referring to the latest RFC about language identification (the latest one is RFC 4646 I believe), then it is kinda complex, and I plan on supporting only part of it (yes, I know this is probably the standard's bane to have partial implementations). A full language tag can be quite long, and that RFC suggests a max "sane" size of 42 bytes. I have actually looked at what I'll do with that this weekend and am currently going with a 15 character string, which should handle easily things like primary tag and one (or two small) secondary tags, like "en_GB". Language plus country should cover most needs. However, it is possible to specify a language override in each data packet, if precision is required. [[User:ogg.k.ogg.k]] Wed Feb 6 12:08:03 UTC 2008		:: Well, I am not certain about this - assuming you are referring to the latest RFC about language identification (the latest one is RFC 4646 I believe), then it is kinda complex, and I plan on supporting only part of it (yes, I know this is probably the standard's bane to have partial implementations). A full language tag can be quite long, and that RFC suggests a max "sane" size of 42 bytes. I have actually looked at what I'll do with that this weekend and am currently going with a 15 character string, which should handle easily things like primary tag and one (or two small) secondary tags, like "en_GB". Language plus country should cover most needs. However, it is possible to specify a language override in each data packet, if precision is required. [[User:ogg.k.ogg.k]] Wed Feb 6 12:08:03 UTC 2008
Line 17:		Line 16:

	:: As a note, Kate uses UTF-8 only at the moment, and supports 31 bit UCS space (if a define is set, off by default), and current code points to 0x10ffff (eg, the currently defined 16 planes). I haven't quite ruled out UTF-16 and UTF-32, but if I add them in, libkate will have an auto conversion option for client code. Note that Kate doesn't concern itself with rules of ligatures, etc, defined by Unicode, that is up to the rendering client. [[User:ogg.k.ogg.k]] Wed Feb 6 12:16:05 UTC 2008		:: As a note, Kate uses UTF-8 only at the moment, and supports 31 bit UCS space (if a define is set, off by default), and current code points to 0x10ffff (eg, the currently defined 16 planes). I haven't quite ruled out UTF-16 and UTF-32, but if I add them in, libkate will have an auto conversion option for client code. Note that Kate doesn't concern itself with rules of ligatures, etc, defined by Unicode, that is up to the rendering client. [[User:ogg.k.ogg.k]] Wed Feb 6 12:16:05 UTC 2008
-

	:::I have learned stuff about unicode. That was stupid of me if you think that I was asking about Unicode supporting it.		:::I have learned stuff about unicode. That was stupid of me if you think that I was asking about Unicode supporting it.
-	I was asking about Kate supporting all unicode features.	+	:::I was asking about Kate supporting all unicode features. (I didn't knew about Unicode having language, country,... mapping.) If you want to tell me that Unicode has a region, language, currency,... mapping on top of a character mapping. Then say it clearly.
-	(I didn't knew about Unicode having language, country,... mapping.)	+
-	If you want to tell me that Unicode has a region, language, currency,... mapping on top of a character mapping.	+
-	Then say it clearly.	+

-	Reading this page: [http://cldr.unicode.org/]	+	:::Reading this page: [http://cldr.unicode.org/]. All the localization stuff are under the name CLDR. CLDR is about the Unicode Common Locale Data Repository. It does a lot more than just language and region mapping.
-	All the localization stuff are under the name CLDR.	+	In fact, the other things are also very useful to have. (e.g. Engineers and the whole scientific community would be very pleased with the number localization.) (Because of the decimal and thousands separator issue: [http://en.wikipedia.org/wiki/Decimal_separator])
-	CLDR is about the Unicode Common Locale Data Repository	+
-	It does a lot more than just language and region mapping.	+
-	In fact, the other things are also very useful to have.	+

-	~~(e.g. Engineers and the whole scientific community would be very pleased with the number localization.)~~	+	:::[[User:Vmol:Vmol]] 31 July 2009
-	~~(Because of the decimal and thousands separator issue~~: [~~http~~:~~//en.wikipedia.org/wiki/Decimal_separator~~] )	+

-	There is a region definitions header present in Kate.	+	There is a region definitions header present in Kate. For the CLDR information, there needs to be a new header. Will there be a CLDR Definitions header or extended Unicode Definitions header somewhere in the future? Please?
-	For the CLDR information, there needs to be a new header.	+
-	Will there be a CLDR Definitions header or extended Unicode Definitions header somewhere in the future?	+
-	Please?	+

	: While I have not looked in depth at the CLDR, I don't think it's something that matters here.		: While I have not looked in depth at the CLDR, I don't think it's something that matters here.
Line 57:		Line 45:
	:That said, I do agree with your argument. [[User:Ogg.k.ogg.k\|Ogg.k.ogg.k]]		:That said, I do agree with your argument. [[User:Ogg.k.ogg.k\|Ogg.k.ogg.k]]

-	==Possible additions restrictions trap==	+	== Possible additions restrictions trap ==

	Please don't restrict your codec from having more than 256 colors in a bitmap.		Please don't restrict your codec from having more than 256 colors in a bitmap.

Ogg.k.ogg.k: /* Possible additions restrictions trap */

2009-08-01T17:15:07Z

Possible additions restrictions trap

← Older revision		Revision as of 17:15, 1 August 2009
Line 66:		Line 66:
	High quality images in OggSpots will look very weird with 256 low-quality images overlays.		High quality images in OggSpots will look very weird with 256 low-quality images overlays.
	It probably won't look good.		It probably won't look good.
		+
		+	: Kate is not limited to 256 color images. These can be encoded natively, but any other PNG
		+	: image may be embedded too, including non paletted images.
		+	: As for MNG, there is a MNG mapping for Ogg too.

	Please do allow the embedding of shared data (fonts).		Please do allow the embedding of shared data (fonts).
Line 78:		Line 82:

	What is your opinion about svgfonts?		What is your opinion about svgfonts?
		+
		+	: I have no opinion about svgfonts, as I do not know about them.
		+	: I have proof of concept support for SVG images in Kate, but there are unresolved issues.
		+	: It'd be nice to have SVG in, and I suppose (but only suppose) SVG fonts would automagically work then. [[User:Ogg.k.ogg.k\|Ogg.k.ogg.k]]

Ogg.k.ogg.k: sign my comment

2009-08-01T17:10:12Z

sign my comment

← Older revision		Revision as of 17:10, 1 August 2009
Line 42:		Line 42:
	: It seems to be more useful to programs' localization. The CLDR would then be more useful in a		: It seems to be more useful to programs' localization. The CLDR would then be more useful in a
	: possible Kate editor, for instance. Once applied, text would go in the Kate stream and the CDLR		: possible Kate editor, for instance. Once applied, text would go in the Kate stream and the CDLR
-	: would not be useful anymore. Feel free to correct me if I'm missing your point though.	+	: would not be useful anymore. Feel free to correct me if I'm missing your point though. [[User:Ogg.k.ogg.k\|Ogg.k.ogg.k]]

	== Embedding of bitmap fonts ==		== Embedding of bitmap fonts ==

Ogg.k.ogg.k: /* Kate is going to have support for all languages in the world, right ? */

2009-08-01T17:08:21Z

Kate is going to have support for all languages in the world, right ?

← Older revision		Revision as of 17:08, 1 August 2009
Line 38:		Line 38:
	Will there be a CLDR Definitions header or extended Unicode Definitions header somewhere in the future?		Will there be a CLDR Definitions header or extended Unicode Definitions header somewhere in the future?
	Please?		Please?
		+
		+	: While I have not looked in depth at the CLDR, I don't think it's something that matters here.
		+	: It seems to be more useful to programs' localization. The CLDR would then be more useful in a
		+	: possible Kate editor, for instance. Once applied, text would go in the Kate stream and the CDLR
		+	: would not be useful anymore. Feel free to correct me if I'm missing your point though.

	== Embedding of bitmap fonts ==		== Embedding of bitmap fonts ==

Vmol: added possible additions restrictions trap

2009-07-31T14:13:24Z

added possible additions restrictions trap

← Older revision		Revision as of 14:13, 31 July 2009
Line 51:		Line 51:
	:text to speech software).		:text to speech software).
	:That said, I do agree with your argument. [[User:Ogg.k.ogg.k\|Ogg.k.ogg.k]]		:That said, I do agree with your argument. [[User:Ogg.k.ogg.k\|Ogg.k.ogg.k]]
		+
		+	==Possible additions restrictions trap==
		+
		+	Please don't restrict your codec from having more than 256 colors in a bitmap.
		+	Applications can do it anyway and didn't these codecs where to create freedom in the first place?
		+	There is nothing wrong with allowing these things and MNG in overlays.
		+	OggSpots is meant for having a timed image track, not for image overlays.
		+	OggKate isn't duplicating because it just isn't in the same scope.
		+	High quality images in OggSpots will look very weird with 256 low-quality images overlays.
		+	It probably won't look good.
		+
		+	Please do allow the embedding of shared data (fonts).
		+	That's a fantastic idea you've got there, don't let it slide.
		+	It would be great to be able to make a font, add it to the file and use it for subtitle's.
		+	It would solve the platform dependency issue with fonts, which is currently a big deal.
		+	(There would even be more freedom added to your codec, this way.)
		+
		+	Please add support for svgfonts.
		+	They have the same advantages for fonts as svg has for images.
		+	It's vector based which means very good looking fonts.
		+
		+	What is your opinion about svgfonts?

Vmol: /* Kate is going to have support for all languages in the world, right ? */

2009-07-31T14:03:32Z

Kate is going to have support for all languages in the world, right ?

← Older revision		Revision as of 14:03, 31 July 2009
Line 29:		Line 29:
	CLDR is about the Unicode Common Locale Data Repository		CLDR is about the Unicode Common Locale Data Repository
	It does a lot more than just language and region mapping.		It does a lot more than just language and region mapping.
-	In fact, the other things are very useful ~~too~~.	+	In fact, the other things are also very useful to have.

-	~~It is very useful to have also the other stuff, not just region.~~
	(e.g. Engineers and the whole scientific community would be very pleased with the number localization.)		(e.g. Engineers and the whole scientific community would be very pleased with the number localization.)
-	(Because of the decimal and thousands separator: [http://en.wikipedia.org/wiki/Decimal_separator] )	+	(Because of the decimal and thousands separator issue: [http://en.wikipedia.org/wiki/Decimal_separator] )

	There is a region definitions header present in Kate.		There is a region definitions header present in Kate.
Line 39:		Line 38:
	Will there be a CLDR Definitions header or extended Unicode Definitions header somewhere in the future?		Will there be a CLDR Definitions header or extended Unicode Definitions header somewhere in the future?
	Please?		Please?
-

	== Embedding of bitmap fonts ==		== Embedding of bitmap fonts ==

Vmol: Answered

2009-07-31T14:01:24Z

Answered

← Older revision		Revision as of 14:01, 31 July 2009
Line 17:		Line 17:

	:: As a note, Kate uses UTF-8 only at the moment, and supports 31 bit UCS space (if a define is set, off by default), and current code points to 0x10ffff (eg, the currently defined 16 planes). I haven't quite ruled out UTF-16 and UTF-32, but if I add them in, libkate will have an auto conversion option for client code. Note that Kate doesn't concern itself with rules of ligatures, etc, defined by Unicode, that is up to the rendering client. [[User:ogg.k.ogg.k]] Wed Feb 6 12:16:05 UTC 2008		:: As a note, Kate uses UTF-8 only at the moment, and supports 31 bit UCS space (if a define is set, off by default), and current code points to 0x10ffff (eg, the currently defined 16 planes). I haven't quite ruled out UTF-16 and UTF-32, but if I add them in, libkate will have an auto conversion option for client code. Note that Kate doesn't concern itself with rules of ligatures, etc, defined by Unicode, that is up to the rendering client. [[User:ogg.k.ogg.k]] Wed Feb 6 12:16:05 UTC 2008
		+
		+
		+	:::I have learned stuff about unicode. That was stupid of me if you think that I was asking about Unicode supporting it.
		+	I was asking about Kate supporting all unicode features.
		+	(I didn't knew about Unicode having language, country,... mapping.)
		+	If you want to tell me that Unicode has a region, language, currency,... mapping on top of a character mapping.
		+	Then say it clearly.
		+
		+	Reading this page: [http://cldr.unicode.org/]
		+	All the localization stuff are under the name CLDR.
		+	CLDR is about the Unicode Common Locale Data Repository
		+	It does a lot more than just language and region mapping.
		+	In fact, the other things are very useful too.
		+
		+	It is very useful to have also the other stuff, not just region.
		+	(e.g. Engineers and the whole scientific community would be very pleased with the number localization.)
		+	(Because of the decimal and thousands separator: [http://en.wikipedia.org/wiki/Decimal_separator] )
		+
		+	There is a region definitions header present in Kate.
		+	For the CLDR information, there needs to be a new header.
		+	Will there be a CLDR Definitions header or extended Unicode Definitions header somewhere in the future?
		+	Please?
		+

	== Embedding of bitmap fonts ==		== Embedding of bitmap fonts ==

Vmol: Corrected spelling mistake, grammer, sentence mistake

2009-05-04T18:17:12Z

Corrected spelling mistake, grammer, sentence mistake

← Older revision		Revision as of 18:17, 4 May 2009
Line 1:		Line 1:
	== Kate is going to have support for all languages in the world, right ? ==		== Kate is going to have support for all languages in the world, right ? ==
-	(This can be ~~userfull~~ to make a video where a user can choose the right subtitle language.)	+	(This can be useful to make a video where a user can choose the right subtitle language.)

	:OggKate supports Unicode (UTF-8), so yes. [[User:Martin.leese\|Martin Leese]] 15:46, 29 January 2008 (PST)		:OggKate supports Unicode (UTF-8), so yes. [[User:Martin.leese\|Martin Leese]] 15:46, 29 January 2008 (PST)
Line 14:		Line 14:
	:: Well, I am not certain about this - assuming you are referring to the latest RFC about language identification (the latest one is RFC 4646 I believe), then it is kinda complex, and I plan on supporting only part of it (yes, I know this is probably the standard's bane to have partial implementations). A full language tag can be quite long, and that RFC suggests a max "sane" size of 42 bytes. I have actually looked at what I'll do with that this weekend and am currently going with a 15 character string, which should handle easily things like primary tag and one (or two small) secondary tags, like "en_GB". Language plus country should cover most needs. However, it is possible to specify a language override in each data packet, if precision is required. [[User:ogg.k.ogg.k]] Wed Feb 6 12:08:03 UTC 2008		:: Well, I am not certain about this - assuming you are referring to the latest RFC about language identification (the latest one is RFC 4646 I believe), then it is kinda complex, and I plan on supporting only part of it (yes, I know this is probably the standard's bane to have partial implementations). A full language tag can be quite long, and that RFC suggests a max "sane" size of 42 bytes. I have actually looked at what I'll do with that this weekend and am currently going with a 15 character string, which should handle easily things like primary tag and one (or two small) secondary tags, like "en_GB". Language plus country should cover most needs. However, it is possible to specify a language override in each data packet, if precision is required. [[User:ogg.k.ogg.k]] Wed Feb 6 12:08:03 UTC 2008

-	:I believe it would be useful if ~~someone~~ went away and learnt something about Unicode. From the Unicode website, "Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language." There are around 7000 written languages in the world. (There is no agreement on an exact figure.) Unicode does the lot. [[User:Martin.leese\|Martin Leese]] 10:06, 5 February 2008 (PST)	+	:I believe it would be useful if the person who asked the question went away and learnt something about Unicode. From the Unicode website, "Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language." There are around 7000 written languages in the world. (There is no agreement on an exact figure.) Unicode does the lot. [[User:Martin.leese\|Martin Leese]] 10:06, 5 February 2008 (PST)

	:: As a note, Kate uses UTF-8 only at the moment, and supports 31 bit UCS space (if a define is set, off by default), and current code points to 0x10ffff (eg, the currently defined 16 planes). I haven't quite ruled out UTF-16 and UTF-32, but if I add them in, libkate will have an auto conversion option for client code. Note that Kate doesn't concern itself with rules of ligatures, etc, defined by Unicode, that is up to the rendering client. [[User:ogg.k.ogg.k]] Wed Feb 6 12:16:05 UTC 2008		:: As a note, Kate uses UTF-8 only at the moment, and supports 31 bit UCS space (if a define is set, off by default), and current code points to 0x10ffff (eg, the currently defined 16 planes). I haven't quite ruled out UTF-16 and UTF-32, but if I add them in, libkate will have an auto conversion option for client code. Note that Kate doesn't concern itself with rules of ligatures, etc, defined by Unicode, that is up to the rendering client. [[User:ogg.k.ogg.k]] Wed Feb 6 12:16:05 UTC 2008

Vmol: corrected spelling mistake, sentence construct

2009-05-04T18:15:09Z

corrected spelling mistake, sentence construct

← Older revision		Revision as of 18:15, 4 May 2009
Line 8:		Line 8:
	::Right to left now supported (in my local version of xine). Language directionality can be overridden for each data packet from the default given in the headers. [[User:ogg.k.ogg.k]] Thurs Jan 31 13:29 UTC 2008		::Right to left now supported (in my local version of xine). Language directionality can be overridden for each data packet from the default given in the headers. [[User:ogg.k.ogg.k]] Thurs Jan 31 13:29 UTC 2008

-	Be ~~carefull~~ to make sure you're using the latest ISO standard (the one with the ~~biggest~~ number) about languages. Because there are already a few so you could miss and ~~use the~~ wrong one.	+	Be careful to make sure you're using the latest ISO standard (the one with the highest number) about languages.
-	For the rest Kate looks so good ;)	+	Because there are already a few so you could miss and end up using a wrong one.
		+	For the rest Kate looks very good ;)

	:: Well, I am not certain about this - assuming you are referring to the latest RFC about language identification (the latest one is RFC 4646 I believe), then it is kinda complex, and I plan on supporting only part of it (yes, I know this is probably the standard's bane to have partial implementations). A full language tag can be quite long, and that RFC suggests a max "sane" size of 42 bytes. I have actually looked at what I'll do with that this weekend and am currently going with a 15 character string, which should handle easily things like primary tag and one (or two small) secondary tags, like "en_GB". Language plus country should cover most needs. However, it is possible to specify a language override in each data packet, if precision is required. [[User:ogg.k.ogg.k]] Wed Feb 6 12:08:03 UTC 2008		:: Well, I am not certain about this - assuming you are referring to the latest RFC about language identification (the latest one is RFC 4646 I believe), then it is kinda complex, and I plan on supporting only part of it (yes, I know this is probably the standard's bane to have partial implementations). A full language tag can be quite long, and that RFC suggests a max "sane" size of 42 bytes. I have actually looked at what I'll do with that this weekend and am currently going with a 15 character string, which should handle easily things like primary tag and one (or two small) secondary tags, like "en_GB". Language plus country should cover most needs. However, it is possible to specify a language override in each data packet, if precision is required. [[User:ogg.k.ogg.k]] Wed Feb 6 12:08:03 UTC 2008

-	:I believe it would be useful if ~~Xpete~~ went away and learnt something about Unicode. From the Unicode website, "Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language." There are around 7000 written languages in the world. (There is no agreement on an exact figure.) Unicode does the lot. [[User:Martin.leese\|Martin Leese]] 10:06, 5 February 2008 (PST)	+	:I believe it would be useful if someone went away and learnt something about Unicode. From the Unicode website, "Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language." There are around 7000 written languages in the world. (There is no agreement on an exact figure.) Unicode does the lot. [[User:Martin.leese\|Martin Leese]] 10:06, 5 February 2008 (PST)

	:: As a note, Kate uses UTF-8 only at the moment, and supports 31 bit UCS space (if a define is set, off by default), and current code points to 0x10ffff (eg, the currently defined 16 planes). I haven't quite ruled out UTF-16 and UTF-32, but if I add them in, libkate will have an auto conversion option for client code. Note that Kate doesn't concern itself with rules of ligatures, etc, defined by Unicode, that is up to the rendering client. [[User:ogg.k.ogg.k]] Wed Feb 6 12:16:05 UTC 2008		:: As a note, Kate uses UTF-8 only at the moment, and supports 31 bit UCS space (if a define is set, off by default), and current code points to 0x10ffff (eg, the currently defined 16 planes). I haven't quite ruled out UTF-16 and UTF-32, but if I add them in, libkate will have an auto conversion option for client code. Note that Kate doesn't concern itself with rules of ligatures, etc, defined by Unicode, that is up to the rendering client. [[User:ogg.k.ogg.k]] Wed Feb 6 12:16:05 UTC 2008