OMR + TEXMAPped unofficial file = ???


OMR + TEXMAPped unofficial file = ???
#1
OMR specification requires to include unofficial files (a very good thing!), but what to do when this unofficial part contains TEXMAP images? Can we imagine a way to include these images in MPD? How to make this compatible with applications that support TEXMAP (afaik LDView, LDCad, LeoCAD and Bricksmith)?

And a 2016 good new year's resolution: have TEXMAP images on Parts Tracker !
Reply
Re: OMR + TEXMAPped unofficial file = ???
#2
This is a very good question.

At present I only can think about a file entry for the picture also! I think that the spec for MPD files already allows this. The only problem we need to solve is that the reader apps needs to be aware of that and can handle it.

just my 5 cent
Reply
Re: OMR + TEXMAPped unofficial file = ???
#4
Michael Heidemann Wrote:At present I only can think about a file entry for the picture also! I think that the spec for MPD files already allows this. The only problem we need to solve is that the reader apps needs to be aware of that and can handle it.
This would need multiple things...

1. Binairy encoding (in order to keep the mpd text based)
2. A new meta to encapsulate said data in one or multiple lines (e.g. 0 !BINDATA FJSJ2321ssdKSKL3LKdDLJSLsdaKFDJL3432LKJ21LJLSJLD.............)
3. A new mpd '0 FILE' variant to identify the subfile as a texture (e.g. 0 !BINFILE TEXMAP image.png)
4. Adjustment to the texture image lookup rules.

All this means it won't work in existing texmap supporting programs out of the box, but it won't break existing mpd support ether.
Reply
Re: OMR + TEXMAPped unofficial file = ???
#5
a solution for embedding images into MPDs could be to use the Data URI scheme:
https://en.wikipedia.org/wiki/Data_URI_scheme
This has the advantage of
- it provides a MIME type
- it allows to use charset UTF-8
- it is text-based
- it is an already established standard (we don't have to re-invent the wheel)

For example, a small image of a red dot could be represented inside an MPD like this:
Code:
0 FILE reddot.png
0 red dot
0 Name: reddot.png
0 Author: Wikipedia
0 !DATA data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==
Reply
Re: OMR + TEXMAPped unofficial file = ???
#6
That sounds good. But why do we need the line "Name: xxxx" and also the line above?

If the line "0 File xxxxx" contain a name with the extension ".png" then it has to be a picture with that name!

We should keep it as simple as possible.
Reply
Re: OMR + TEXMAPped unofficial file = ???
#7
Yes, of course. The example above results from saving a dummy MPD file with MLCad and then just adding the !DATA line.
Reply
Re: OMR + TEXMAPped unofficial file = ???
#3
Yes, one of my aims too.
Chris (LDraw Parts Library Admin)
Reply
Re: OMR + TEXMAPped unofficial file = ???
#8
Please add a simple file with picture to this thread that make use of TEXMAP. So we are able to let our thoughts flow Smile
Reply
Re: OMR + TEXMAPped unofficial file = ???
#9
Exemple of a TEXMAPped part: http://www.ldraw.org/cgi-bin/ptdetail.cg...13710a.dat
Texture file attached here
   
Reply
Re: OMR + TEXMAPped unofficial file = ???
#10
Thank you.

Now I need to find a way to transform the picture in Visual Basic Smile
Got it!

The DATA according to Firefox is like follows:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAlsAAAEFCAYAAADUqSJrAAAgAElEQVR4nOydd3CbVbr/c3937sydO3fuX3tnduYSYAGnhxBKElpCCQkJsIQaOlkgENgQCKEmWUIglARCKIHNEkKsYtmyLNlqli2523LvluTee3vVe/n+/nhjxYokW7Ily07OZ+aZBenV+57zSvj97DnPec4iEAiEsLDb7dBoNMiUZ4CTmIB4xnnEM86DxWZCKEpDkbIQmkYNRkZG4HK5Yt1cAoFAIMSYRbFuAIGwUPB4PGhQNSCBw.......

Sadly the code is too long for the forum.
Reply
Re: OMR + TEXMAPped unofficial file = ???
#11
Hey Michael,

Michael Heidemann Wrote:Now I need to find a way to transform the picture in Visual Basic Smile

that should be very easy. I think you are using .Net, so have a look at Convert.ToBase64String(Byte[]).

Rolf
Reply
Re: OMR + TEXMAPped unofficial file = ???
#12
Yes, that is correct. Yesterday evening I also found that function Smile.

I'll keep you informed about my progress on this in MPDCenter.
Reply
RE: OMR + TEXMAPped unofficial file = ???
#32
(2016-01-03, 17:01)Philippe Hurbain Wrote: Exemple of a TEXMAPped part: http://www.ldraw.org/cgi-bin/ptdetail.cg...13710a.dat
Texture file attached here

I've been reading through multiple Forum Posts, looking for Basic Texmap Instructions.  We're trying to load textures in to Bricksmith Version 3.0 (3.0) and use them for instruction creation in LPub 4.0.0.10, on a MAC Mini OS 10.  I opened your part 13710a.dat in Bricksmith to take a look, thanks for the example, and by replacing a few parts and the texture, I was able to see my texture appear in Bricksmith.
 
Once I opened your example in Bricksmith I noticed a square 4 color icon with image attached in the File Contents.  Can you explain how that's created in Bricksmith 3.0?  We're also not having any luck getting any images to show in LPub 4, using LDView, and LDGlite (preferred).  

Any help is welcome.  Thanks in advance.
Reply
RE: OMR + TEXMAPped unofficial file = ???
#33
(2018-03-07, 21:13)John Canepa Wrote:
(2016-01-03, 17:01)Philippe Hurbain Wrote: Exemple of a TEXMAPped part: http://www.ldraw.org/cgi-bin/ptdetail.cg...13710a.dat
Texture file attached here

I've been reading through multiple Forum Posts, looking for Basic Texmap Instructions.  We're trying to load textures in to Bricksmith Version 3.0 (3.0) and use them for instruction creation in LPub 4.0.0.10, on a MAC Mini OS 10.  I opened your part 13710a.dat in Bricksmith to take a look, thanks for the example, and by replacing a few parts and the texture, I was able to see my texture appear in Bricksmith.

Once I opened your example in Bricksmith I noticed a square 4 color icon with image attached in the File Contents.  Can you explain how that's created in Bricksmith 3.0?  We're also not having any luck getting any images to show in LPub 4, using LDView, and LDGlite (preferred).  

Any help is welcome.  Thanks in advance.

First of all, I don't know anything about the details of Bricksmith, so I don't know what's up with the icon you talk about.

As far as I know, LDGlite does not support textures. I could be wrong about this. In order for the textures to work in LDView, you need to have the PNG image file be located either in the same directory as the part's .dat file, or in a textures sub-directory of where the part is located. (The intent for official parts is that the textures will be in a textures subdirectory.)

At this point in time, creating your own custom textured parts requires a lot more knowledge than simply using a GUI to create a model. There are various instructions here on forums.ldraw.org for creating custom textured parts.

You should check to see which version of LDView LPub is using. I would recommend using the latest release (4.3). I don't remember when texture support was added, but they definitely work in LDView 4.3.
Reply
RE: OMR + TEXMAPped unofficial file = ???
#38
(2018-03-08, 0:32)Travis Cobbs Wrote:
(2018-03-07, 21:13)John Canepa Wrote: I've been reading through multiple Forum Posts, looking for Basic Texmap Instructions.  We're trying to load textures in to Bricksmith Version 3.0 (3.0) and use them for instruction creation in LPub 4.0.0.10, on a MAC Mini OS 10.  I opened your part 13710a.dat in Bricksmith to take a look, thanks for the example, and by replacing a few parts and the texture, I was able to see my texture appear in Bricksmith.

Once I opened your example in Bricksmith I noticed a square 4 color icon with image attached in the File Contents.  Can you explain how that's created in Bricksmith 3.0?  We're also not having any luck getting any images to show in LPub 4, using LDView, and LDGlite (preferred).  

Any help is welcome.  Thanks in advance.

First of all, I don't know anything about the details of Bricksmith, so I don't know what's up with the icon you talk about.

As far as I know, LDGlite does not support textures. I could be wrong about this. In order for the textures to work in LDView, you need to have the PNG image file be located either in the same directory as the part's .dat file, or in a textures sub-directory of where the part is located. (The intent for official parts is that the textures will be in a textures subdirectory.)

At this point in time, creating your own custom textured parts requires a lot more knowledge than simply using a GUI to create a model. There are various instructions here on forums.ldraw.org for creating custom textured parts.

You should check to see which version of LDView LPub is using. I would recommend using the latest release (4.3). I don't remember when texture support was added, but they definitely work in LDView 4.3.
Thanks for the reply.  I am now using LDview 4.3.  I can see my textures in Bricksmith, and in LDview, but still can't see them in LPub 4.  I updated the path to LDview, and it's now my is my selected renderer.  Again, any assistance is greatly appreciated.
Reply
RE: OMR + TEXMAPped unofficial file = ???
#39
(2018-03-13, 15:45)John Canepa Wrote: Thanks for the reply.  I am now using LDview 4.3.  I can see my textures in Bricksmith, and in LDview, but still can't see them in LPub 4.  I updated the path to LDview, and it's now my is my selected renderer.  Again, any assistance is greatly appreciated.

It's possible that LPub4 copies the part file into its cache while rendering, in which case the texture would not be copied, which would lead to it not showing. Try putting your textured part file in <LDraw Dir>/Unofficial/parts, and the texture in <LDraw Dir>/Unofficial/parts/textures.
Reply
Re: OMR + TEXMAPped unofficial file = ???
#13
I have some questions :

Will this replace patterns one day?
How is dedined the png resolution?
Won't iz be better to use some kind of vectorial image format instead of pixels-based one?
Reply
Re: OMR + TEXMAPped unofficial file = ???
#14
Damien Roux Wrote:Will this replace patterns one day?
I doubt it as most patterns are fairly square and thus easy to model. In such cases the old method will offer higher quality as it is basically vector based.
Damien Roux Wrote:How is dedined the png resolution?
There is no real limit I know of but in the practice you propably need to keep it below 1 megapixel to keep the OpenGL/directX usage universal.
Damien Roux Wrote:Won't iz be better to use some kind of vectorial image format instead of pixels-based one?
For the low detail ones the old method offers vector quality, for very complicated things a high res texture would be good enough. But if needed we can also add other formats then png to the standard but they will be harder to implement.
Reply
Re: OMR + TEXMAPped unofficial file = ???
#15
BTW....: we already _have_ a vectorial image format: LDRAW...
Yes, it is much simpler than e.g. SVG, but if you want to create a pattern as vector graphics - you already can..........
Reply
Re: OMR + TEXMAPped unofficial file = ???
#16
I dream of somebody improving on Travis SvgToDat converter...
Reply
Re: OMR + TEXMAPped unofficial file = ???
#17
You mean: better traingulation?
Reply
Re: OMR + TEXMAPped unofficial file = ???
#18
Yes, and possibly support of more svg features (eg. paths)
Reply
Re: OMR + TEXMAPped unofficial file = ???
#19
Wow, I totally forgot about even writing that. If anyone is interested in picking up where I left off, I'll post the source code somewhere.
Reply
RE: OMR + TEXMAPped unofficial file = ???
#23
(2016-01-05, 8:09)Philippe Hurbain Wrote: I dream of somebody improving on Travis SvgToDat converter...

Where can I find details of the SvgToDat converter? The link on this post comes up with the message "The specified thread does not exist."
Reply
RE: OMR + TEXMAPped unofficial file = ???
#24
(2016-08-17, 17:11)Reuben Pearse Wrote:
(2016-01-05, 8:09)Philippe Hurbain Wrote: I dream of somebody improving on Travis SvgToDat converter...

Where can I find details of the SvgToDat converter? The link on this post comes up with the message "The specified thread does not exist."

Here is the original post where I published my first test build (which is the only one ever) of the program:

http://forums.ldraw.org/thread-593-post-720.html#pid720

That was almost exactly 5 years ago. I'd be happy to publish the source code if anyone is interested in taking it further. The download link in that post is still valid, but you need to read the post before trying it out.
Reply
Re: OMR + TEXMAPped unofficial file = ???
#20
Any new ideas about this? Chances for new specs? For compatible viewers/editors?
Reply
Re: OMR + TEXMAPped unofficial file = ???
#21
I think Steffen's example:

Code:
0 FILE reddot.png
0 red dot
0 Name: reddot.png
0 Author: Wikipedia
0 !DATA data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==

Is very usable/implementable. It just needs some global rules. Like, e.g.:

"when a !DATA is used in all other lines except header descriptive ones most be ignored."
"Only the image/png;base64 variant is supported."

and maybe limit the file extension, but I don't think that is actually needed as the texture can be detected by the presence of the data meta alone.
Reply
Re: OMR + TEXMAPped unofficial file = ???
#22
- yes, we should require these restrictions
- I suggest to also allow image/jpg and image/jpeg (which mean the same)
- to avoid that all users are forced to just use 1 (potentially very long) line, we could allow that that line is splitup into multiple ones, each starting with !DATA
Reply
RE: OMR + TEXMAPped unofficial file = ???
#25
Reviving this thread, I have some suggested modifications. I don't think we should make this MPD-specific. Instead, I think we should add a new !DATA meta that requires a filename prior to the base64-encoded data. The decoded contents of the base64 data would then be treated as the specified file. (In theory, an ldr file could even be encoded and then referenced, but this would be strongly discouraged.)

Also, I think we should conform to e-mail-compatible base64 encoding, meaning that we should only have 76 encoded characters per line. Each line would begin with "0 !:" (like used in !TEXMAP itself). Something like:

Code:
0 !DATA BEGIN 19204p01.png
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END

(Note that I only included the first 4 lines of the base64-encoded version of 19204p01.png.)

It would be illegal to have a !DATA statement between a !TEXMAP BEGIN and !TEXMAP END, or immediately following a !TEXMAP NEXT.
Reply
RE: OMR + TEXMAPped unofficial file = ???
#26
(2018-01-05, 20:54)Travis Cobbs Wrote: Reviving this thread, I have some suggested modifications. I don't think we should make this MPD-specific. Instead, I think we should add a new !DATA meta that requires a filename prior to the base64-encoded data. The decoded contents of the base64 data would then be treated as the specified file. (In theory, an ldr file could even be encoded and then referenced, but this would be strongly discouraged.)

Also, I think we should conform to e-mail-compatible base64 encoding, meaning that we should only have 76 encoded characters per line. Each line would begin with "0 !:" (like used in !TEXMAP itself). Something like:

Code:
0 !DATA BEGIN 19204p01.png
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END

(Note that I only included the first 4 lines of the base64-encoded version of 19204p01.png.)

It would be illegal to have a !DATA statement between a !TEXMAP BEGIN and !TEXMAP END, or immediately following a !TEXMAP NEXT.

I like the format but I still think an embedded png (or any non ldraw file) should have its own FILE section as it can be referenced from multiple models/parts.

So maybe
Code:
0 FILE 19204p01.png
0 Texture for 19204p01
0 Name: 19204p01.png
0 Author: Philippe Hurbain [Philo]
0 !LDRAW_ORG Texture UPDATE 2018-01
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 !DATA BEGIN
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END
Reply
RE: OMR + TEXMAPped unofficial file = ???
#27
I like the proposal. I tested an mpd with an embedded image with MLCad, LDCad, MPDCenter, MPDwizard. Of course the texture didn't work, but I got no weird behaviour. Only minor drawback: if I extract mpd files, a .png is created while the file with header and uuencoded content is NOT a png file.
Reply
RE: OMR + TEXMAPped unofficial file = ???
#28
(2018-01-07, 15:25)Philippe Hurbain Wrote: I like the proposal. I tested an mpd with an embedded image with MLCad, LDCad, MPDCenter, MPDwizard. Of course the texture didn't work, but I got no weird behaviour. Only minor drawback: if I extract mpd files, a .png is created while the file with header and uuencoded content is NOT a png file.

I expect most programs would see it as an empty model, unless they restrict the extensions for some reason.

I'm not sure about the file type specification though, using
Code:
0 !LDRAW_ORG Texture UPDATE 2018-01

Might be to restrictive as we would have to add keys for all filetypes, maybe a more generic :
Code:
0 !LDRAW_ORG Data UPDATE 2018-01
Combined with the program interpreting the file extension given in FILE or the filename itself would be enough.

You could also use, e.g.:
Code:
0 unofficial data
in mpd's etc.

Probably its only use, as official libraries should distribute the png as is, although this setup would allow for an png to be wrapped by a non .mpd .ldr named .png Smile
Reply
RE: OMR + TEXMAPped unofficial file = ???
#31
(2018-01-05, 21:27)Roland Melkert Wrote: I like the format but I still think an embedded png (or any non ldraw file) should have its own FILE section as it can be referenced from multiple models/parts.

So maybe
Code:
0 FILE 19204p01.png
0 Texture for 19204p01
0 Name: 19204p01.png
0 Author: Philippe Hurbain [Philo]
0 !LDRAW_ORG Texture UPDATE 2018-01
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 !DATA BEGIN
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END

I can't think of any reason the !LDRAW_ORG or LICENSE lines would ever be used. I'm not in any way suggested that this be used in official parts as a stop-gap measure until the parts tracker can be updated to allow textures. (Note that doing that would require approval by the LSC, since parts have an explicit list of meta commands that they are allowed to use. I for one would almost certainly vote against allowing this.) The whole point here (by my understanding) is for unofficial parts to be able to be included in an MPD.

In fact, I'm kind of dubious about having any header information in the file at all. A program generating this wrapper only has a PNG file as its input. Sure, it could prompt the user for the other info, but I think it needs to be assumed that all that info would match the file the texture is reference from. That's all that can be done with PNG texture files, so supporting more data for wrapped texture files just encourages wrapping them in situations where that is clearly not the optimal solution. And my original suggestion (not using 0 FILE) was meant to be included anywhere in a model, and then be just as global as a 0 FILE entry would be. The argument for using 0 FILE is that it's already standard, and I can accept that. But adding metadata to the MPD file entry just seems wrong to me.
Reply
RE: OMR + TEXMAPped unofficial file = ???
#34
Going mostly with Roland's suggestion (but without any header data), I created an MPD with an embedded checker texture (attached). It looks like this when opened:

[Image: Ybt9n2P.png]

Some notes about my implementation:
  • I changed BEGIN to START to be consistent with !TEXMAP.
  • I only support START/END, not NEXT.
  • I'm only officially supporting !DATA in MPD files (since that's the whole point).
  • Only one !DATA entry is allowed per 0 FILE entry in the MPD.
  • When parsing the BASE64 text, I ignore any characters that aren't in the BASE64 character set, so a space after the 0 !: shouldn't break my parser.


Attached Files
.mpd   texTest3.mpd (Size: 1.99 KB / Downloads: 3)
Reply
RE: OMR + TEXMAPped unofficial file = ???
#35
(2018-03-09, 5:02)Travis Cobbs Wrote: Some notes about my implementation:
  • I changed BEGIN to START to be consistent with !TEXMAP.
  • I only support START/END, not NEXT.
  • I'm only officially supporting !DATA in MPD files (since that's the whole point).
  • Only one !DATA entry is allowed per 0 FILE entry in the MPD.
  • When parsing the BASE64 text, I ignore any characters that aren't in the BASE64 character set, so a space after the 0 !: shouldn't break my parser.

Looks simply enough, makes me want to implement it in LDCad too.

Ignoring characters might be a problem for some parser implementations as they are usually hidden from the programmer. So I think we should state in the spec the !DATA content should be trimmed while reading but must be all base64 in the middle.

We also might need to force a multiple of 3 characters per line as base64 is grouped by 24 bits (hence the 1 or 2 trailing '=' chars)
Reply
RE: OMR + TEXMAPped unofficial file = ???
#36
(2018-03-09, 19:07)Roland Melkert Wrote: Ignoring characters might be a problem for some parser implementations as they are usually hidden from the programmer. So I think we should state in the spec the !DATA content should be trimmed while reading but must be all base64 in the middle.

I'm perfectly fine with saying that the BASE64 data cannot contain internal garbage, but have optional white space after the !:, and optional white space after the BASE64 data on each line.

(2018-03-09, 19:07)Roland Melkert Wrote: We also might need to force a multiple of 3 characters per line as base64 is grouped by 24 bits (hence the 1 or 2 trailing '=' chars)

Actually, that's 4, since BASE64 encodes 6 bits per ASCII character, to yield 3 binary bytes per 4 ASCII characters. LDView will give an error if the BASE64 input length is not an even multiple of 4.
Reply
RE: OMR + TEXMAPped unofficial file = ???
#37
(2018-03-09, 20:19)Travis Cobbs Wrote:
(2018-03-09, 19:07)Roland Melkert Wrote: We also might need to force a multiple of 3 characters per line as base64 is grouped by 24 bits (hence the 1 or 2 trailing '=' chars)

Actually, that's 4, since BASE64 encodes 6 bits per ASCII character, to yield 3 binary bytes per 4 ASCII characters. LDView will give an error if the BASE64 input length is not an even multiple of 4.

I also don't think that we should care about how many BASE64 characters are on each line. What matters is that the whole BASE64 block is an even multiple of 4 characters. I don't think decoding the data line-by-line is a good idea. (My implementation concatenates all the BASE64 data into one block and then decodes it.)
Reply
RE: OMR + TEXMAPped unofficial file = ???
#29
(2018-01-05, 20:54)Travis Cobbs Wrote: Reviving this thread, I have some suggested modifications. I don't think we should make this MPD-specific. Instead, I think we should add a new !DATA meta that requires a filename prior to the base64-encoded data. The decoded contents of the base64 data would then be treated as the specified file. (In theory, an ldr file could even be encoded and then referenced, but this would be strongly discouraged.)

Also, I think we should conform to e-mail-compatible base64 encoding, meaning that we should only have 76 encoded characters per line. Each line would begin with "0 !:" (like used in !TEXMAP itself). Something like:

Code:
0 !DATA BEGIN 19204p01.png
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END

(Note that I only included the first 4 lines of the base64-encoded version of 19204p01.png.)

It would be illegal to have a !DATA statement between a !TEXMAP BEGIN and !TEXMAP END, or immediately following a !TEXMAP NEXT.

Splitting to multiple lines will cause the user to have to scroll by huge amounts in programs that show the LDR source code. Is MLCAD the only program that still does this?
Reply
RE: OMR + TEXMAPped unofficial file = ???
#30
(2018-01-07, 19:39)Michael Horvath Wrote: Splitting to multiple lines will cause the user to have to scroll by huge amounts in programs that show the LDR source code. Is MLCAD the only program that still does this?

I think not splitting to multiple lines is just asking for trouble. Many text editors are likely to be unhappy with 250,000-byte lines.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 2 Guest(s)
Forum Jump:


Users browsing this thread: 2 Guest(s)