Login

eeyore · (This post was last modified: 2013-04-20, 18:55 by Don Heyse.)

Hi all
I'm new to the program and have to say I'm loving every second I use of it.
The only issue I have really is that as a new person I'm having a bit of a mission finding the parts I want. I know there are websites with parts and bigger pictures of them but is there a Catalogue for off line use?

I mainly use the Lego cad on my laptop (big screen and lots of ram!) and normally out of 3G signal so i would find a sort of PDF parts catalogue really usefull if there is one.

**Steffen** · 2012-07-26, 21:20

I'm not sure if I understood you correctly.

Are you asking how and what to download?
Then your question coincides with the topic which I just have brought up:
http://forums.ldraw.org/showthread.php?t...49#pid5649

Once you have all wanted files on your harddisk
(most probably simply "all official ones"),
many of the tools allow you to browse the parts interactively.

PS
I also would appreciate a beautifully rendered
"all official parts" PDF
(i.e., not only the parts within an incremental update,
but the entirety of our library)
- simply for browsing fun. I love looking at all our parts...

***Willy Tschager*** · 2012-11-30, 8:41

I get this request quite often and would love to add such a cataloge to the AIOI. I could render thumbnails of the parts folder's content by running a LDView batch file but this is just half the job.

* Ideal would be a script which generates PDF pages with a header (Image/Number/Description)
* Comes with a search string feature. Something down the line of the search feature in MLCad, with <Brick, Plate>, <Minifig & !Torso, ...
* Let's me change the color of the thumbnails via LDraw color number or general color picker
* Does also a little bit of formatting as LDView does for it's Parts List
* Would not rely on existing image databases. It would use it's own renderer or an external viewer. Databases on Peeron or Bricklink do not have images of all part in all colors.

Anybody out there with the required skills and a bit of spare time left?

w.

**Chris Dee** · 2012-12-02, 16:36

Willy Tschager Wrote:Databases on Peeron or Bricklink do not have images of all part in all colors.
w.

Which is only because last time I tried to regenerate the entire library in all the LDConfig.ldr colours (which should be done at each Parts Update), we ran out of disk space on the server - and crashed the Parts Tracker.

**Michael Heidemann** · 2012-12-02, 17:31

Maybe I can be the one you are looking for if ldvlib.dll can save images.

I should be able to create whatever you need, if the data are in the library files.

If we are going to have a PDF file you do not need to have search capability in the application as you can search in the PDF file.

I can think of 4 pieces on one page on the left side and on the right side all necessary data are listed. Attached you find such a pdf as quick hack (delete the last 4 characters from the filename after saving to your hard disc).

**Travis Cobbs** · 2012-12-03, 2:15

I started working on a shell script to do this with LDView from the command line. Unfortunately, I ran into an LDView bug (LDView crashing when rendering many parts on the command line), so I need to fix that before I can continue with my script. Assuming I fix the crash, I should be able to produce a script. However, the script is a bash script, which will work great in Linux and on the Mac, but will require bash and associated helper commands to be installed in order to work in Windows. (Associated commands are things like sed and tr, plus basic stuff like mkdir and rm, which should be present in any bash for Windows.)

***Willy Tschager*** · 2012-12-03, 9:27

With currently some 5000 parts in the library you would get some 1200(!) pages by putting only 4 parts on every page. I think something like this:

http://www.holly-wood.it/tmp/Parts%20Catalog.pdf

(with in mind that some crazy head actually try to print the catalogue for a handy use) would do a better job.

w.

***Willy Tschager*** · 2012-12-03, 9:31

Well, it's not that I pretend compiling such a catalogue by myself on my win notebook. As long as I get a fine pdf (the way I want it ;-) for the AIOI I'm more than happy to delegate all the workload to linux or mac users.

w.

**Michael Heidemann** · 2012-12-03, 17:05

Ok, just a list of the parts like already in parts.lst, but with pictures - should not be that difficult.
My only concers are at present the pictures. I'll have to check how I have done in my OMRMaker.
But keep in mind, that you can not see much details of the parts if the parts much larger than an 1 x 1 Brick !

One more thought about your suggestion - There is no additional information like KEYWORDS or CATEGORY in your suggestion. I think that should be included, as it can be found by searching for a specific text!

**Travis Cobbs** · 2012-12-03, 19:51

I got the crash bug fixed, but ran into another one (apparently related to SaveSnapshots with multiple input files). I still need to investigate that. I'm sending the parts to LDView 100 at a time to make it run faster, and for three or four of the batches (out of the 6000+ parts), LDView just stops for some reason part-way through.

I got Chris Dee to send me the command line options he's using for the ldraw.org part images, so the images I end up generating should match those, once I'm done.

One nice thing is that the Mac has print-to-PDF built in as a standard feature of its Print Dialog, so I don't have to worry about installing a converter. I just have to try to find a web browser that nicely paginates. (Last I checked, Firefox didn't; hopefully Safari or Chrome will.)

**Travis Cobbs** · 2012-12-05, 17:28

Well, I generated a list in HTML format for all the parts whose filename starts with 4. (This makes testing more managable.) I then printed that to a PDF. Unfortunately, none of the browsers I tried (Firefox, Chrome, Safari, and Opera on the Mac, IE 9 on Win 7) did a very good job with page breaks. The best was Firefox, and it's not exactly great. You can see the (6.4MB) PDF here:

http://www.halibut.com/~tcobbs/ldraw/pri...4Parts.pdf

Let me know what you think.

Note that my generated HTML includes a "page-break-inside: avoid;" CSS tag for <tr> elements, and Opera is supposed to support that CSS tag. However, either I did it wrong, or Opera's claimed support is bady broken, because it actually ended up looking a lot worse on Opera than on Firefox. (Firefox isn't supposed to support that particular CSS tag.) Also, Firefox was the only browser that included the header at the top of each page.

**Roland Melkert** · 2012-12-05, 18:17

Why not just leave it html ? A collection of jpg's and html files is just as useable offline as a large (slow) pdf. Even simple search will work using the browsers ctrl+f or maybe some javascript.

**Travis Cobbs** · 2012-12-05, 18:55

That's a good point. I don't have a problem leaving it as HTML, but I feel it should be pointed out that the full list HTML page is brutal on web browsers, and the PDF version would likely in fact be faster. (I think Adobe Reader only loads the visible pages, not the whole document. Loading 6000+ images all at once in a web browser can in fact be slow.)

Right now, the HTML I generate is sorted based on the filename (because that was easiest), but I could see sorting based on the part description, and dividing it into a separate HTML page for each category, with a main page with links to each category. That would cut down on the size of any given page.

**Roland Melkert** · 2012-12-05, 20:03

The huge amount of pictures might be a problem indeed, although some browsers are getting 'less good' at wasting resources. Smile

Adding the picture dimensions to the img tags (if not so already) might help. That way the browser can format the page without reading all the actual images, i could imagine some optimizations are based on that information.

Or make multiple html files, linked to by (cross) index page(s).

***Willy Tschager*** · 2012-12-06, 19:28

Well, it looks promising as a starting point. Personally I would prefer to see the pics aligned to the left - but this is taste. Did you succeed with the page-break in the meantime?

I'm not so sure about the html versus pdf. I guess a pdf is in this case just what people expect from this type of thing. On the other side I prefer a html if the page-break is not fixable.

w.

**Michael Heidemann** · 2012-12-06, 20:51

Just another thought.
I have seen html pages that are generated from xml files with xsl format rules. By doing this you can quickly change the sort order of things.
Maybe it's too slow on the other hand because it has to be one large file. IMHO.

**Travis Cobbs** · 2012-12-07, 0:56

The images are right justified because otherwise there is a huge gap between small parts and the other columns. Moving the images to be the last column would allow them to be left-justified.

I didn't have any luck on the page breaks, and unless Firefox adds support, I don't see that changing. (None of the other browsers repeated the table header at the top of each page.)

**Michael Heidemann** · 2012-12-09, 15:46

I also got LDView crashed twice on part no. 2700.dat if running in batch mode.
Maybe this is already fixed, but I like to mention it. I used Version 4.1 under windows xp.

**Michael Heidemann** · 2012-12-09, 17:48

Currently I am generating for each of the 6774 part a picture, sized 80 x 60. It is still not finished and I have currently already 29 Mb of filesize in the picture folder.
I think it will be in the end nearly 35 Mb only for the pictures.

Is it really a good idea to have all parts with pictures in one pdf file?

It is just ready: 40,3 MB (42.355.647 Bytes) disc space is lot more due to cluster size.

**Travis Cobbs** · 2012-12-10, 2:35

I'm using similar logic to what Chris Dee uses on LDraw.org to generate autocropped pictures with consistent zoom factor. I use 512x512 as the maximum image size, but position the camera at a set distance, so that most parts get cropped to be much smaller than 512x512. My end result is around 50MB.

Right now, I'm working on dividing the output up into a separate HTML page for each category. Having all 6000+ images in one page was causing problems in some web browsers.

Unless we can come up with a way to nicely paginate the results, combining everything into a single PDF isn't really useful. Having said that, Adobe Reader shouldn't have any problems viewing such a file, no matter how big. It doesn't load everything into memory up front as far as I know. In fact, I have an option in my script to generate all the images twice as big, then show them in the HTML page at 50% scale so that they will look nicer in the PDF. Since I'm not generating a PDF, I'm not using that option, although I suppose it would also produce really cool results on Apple devices with Retina displays.

**Travis Cobbs** · 2012-12-10, 2:41

The crash I fixed was related to ~Moved to parts, and 2700 isn't a ~Moved to. So, I don't think my fix will fix the crash you're seeing. I haven't personally seen a crash for that part, but I will test some more. What version of LDView are you using?

**Michael Heidemann** · 2012-12-10, 19:28

Code:
I used Version 4.1 under windows xp

**Michael Heidemann** · 2012-12-10, 19:40

Two days needed my computer to build all (pictures, html page, pdf file).

Visual Parts Catalogue (now hosted at Google Drive)

Please let me know what you think.

**Travis Cobbs** · 2012-12-11, 0:27

Hopefully that means that I fixed the bug in my 4.2 tree, but I'll see if 2700 crashes for me when using LDView 4.1 from the command line.

**Travis Cobbs** · 2012-12-11, 0:40

Do you mean that the computer itself spent 2 days rendering the content?

The one I'm working on takes my 4 year old Macbook about 15 minutes to generate all the images and HTML (using a bash script). The PDF output I got from printing from web browsers didn't look good; I didn't try importing into OpenOffice, though.

I have spent a fair amount of time on and off over a number of days working on the script, so if you did everything, including writing the tools to generate the output in two days, that's good.

The file looks really nice. It's paginated quite nicely, which is something I didn't get when trying to use web browsers.

**Michael Heidemann** · 2012-12-11, 17:09

No, not only rendering. That took approx. about 10 hours, but as I had several crashes (not only 2700.dat) and that caused by app to wait.
My system is about 7 years old (1.3 GHz - single core), so I expect that it should be done faster if running on an uptodate system.

I should have also mentioned that I reduzed the resolution of the pictures on PDF creation process because of saving filesize.

OpenOffice should also give good results with your html source as I think that the page brake in PDF export will be done only for full table row.

By the way, how should the command line looks like, if I like to have all pictures showing the parts in the same ratio (small picture for small parts - large picture for large parts) ?

**Travis Cobbs** · 2012-12-11, 18:21

I need to modify my script to output both categorized HTML and a full list HTML. (I modified it to categorize the parts so that the individual HTML files would be smaller, because the big one was crashing some browsers.) Once I do that, I'll give OpenOffice a try for the PDF generation.

For consistent scale parts, I'm using settings that Chris Dee and I together worked out for the parts tracker. (I did the initial work, and he tweaked it to make things work better.) The parts are first divided into three categories: baseplates, panels, and everything else.

Baseplates are straightforward: the first word of their name is "baseplate". (You have to parse "~Moved to" lines to find the final name, otherwise "~Moved to" baseplates won't get recognized as baseplates.) Baseplates get rendered at half the scale of everything else.

Panels are identified by a short list of filename patterns, and get rendered from the opposite side so that you can see their printing, which would otherwise be on the back.

For the command line, I use the following options for all three categories:

Code:
-SaveWidth=512 -SaveHeight=512 -SaveZoomToFit=0 -SaveAlpha=1 -AutoCrop=1 -FOV=0.1

For baseplates, I use the following:

Code:
-cg30,45,600000

For panels, which are recognized based on their filename with a regex of "^(4864|6268|4215|2362|4865|4345ap|4345bp)[^0-9].*", I use the following:

Code:
-cg-30,225,300000

For everything else, I use the following:

Code:
-cg30,45,300000

Note: the big numbers above (600000 and 300000) are from my memory. I tweaked the values that Chris sent me (400000 and 275000), so they might not be exactly correct.

Also note that a few parts (48x48 baseplate, really large train bases) get clipped by the above settings. There are few possible solutions to that:

Pull the camera back for everything to draw everything at a smaller scale.
Pull the camera back just for them to draw them at a smaller scale.
Pull the camera back, but increase the maximum image dimensions by a comparable amount.
Some combination of the above.

***Philippe Hurbain*** · 2012-12-11, 18:34

Excellent work! Perhaps there could be two versions, one targeting file size (this one is great for that) and one with better image quality/lower compression?

**Michael Heidemann** · 2012-12-11, 22:06

I also like to add in the final version the category and the keywords, so you can search also for that strings. I think that I need then a smaller size for the letters.
I'll keep you updated.

**Michael Heidemann** · 2012-12-11, 22:07

Thank you very much for your detailed information. I'll have to see how I can incorporate that.
I'll keep you updated.

**Travis Cobbs** · 2012-12-12, 5:37

I just checked my script, and the big numbers I use in the -cg option are 275000 and 550000, not 300000 and 600000.

Paul Griffin · 2012-12-18, 2:38

Has nobody considered implementing this in LaTeX? I would think you could automate a lot of these tasks (after generating a bash script) and not have to worry about the intermediate rendering.

**Tim Gould** · 2012-12-18, 2:42

Have you ever tried to get LaTeX to properly process a long table with many pictures? I know it works in principle, but in my fairly extensive experience that relies on the two aspects of LaTeX that are least reliable.

Tim

**Travis Cobbs** · 2012-12-18, 2:56

I never learned LaTeX, so I went with what I knew (HTML).

As it turns out, OpenOffice and LibreOffice can both do a fairly good job of importing the huge HTML table and paginating the result, and both support PDF export. I have created two PDF documents (one standard, one with double-resolution images) and sent them to Willy, and he plans to make them available in the not-too-distant future (hopefully by the end of the year or early next year). For reference, the PDF with standard resolution images is approximately 34MB, and the one with double-resolution images is approximately 74MB. Both use lossless image compression inside the PDF, instead of JPEG.

FYI, the PDF documents are 821 pages long, so I doubt anyone will be printing them.

**Michael Heidemann** · 2012-12-18, 16:49

Did you also print the keywords to each part if they are present?

**Travis Cobbs** · 2012-12-18, 18:28

No, I didn't. They wouldn't really fit, given the size of the pictures I used. I'd like to generate a separate document that has those but no pictures that could be used as a cross-reference to the document with pictures. Another alternative would be to have the PDF document be in landscape, in which case a keywords column would probably fit.

***Willy Tschager*** · 2012-12-18, 19:18

Travis Cobbs Wrote:sent them to Willy, and he plans to make them available in the not-too-distant future (hopefully by the end of the year or early next year).

I would upload the high quality PDF immediately if only the download module of our CMS wouldn't be broken. Orion is working on it. As for the HTML version the Content Managers are discussing where it is best suited to store.

w.

**Travis Cobbs** · 2012-12-18, 20:16

Just to clarify, the files are 34.3MB for the standard one, and 73.6MB for the high-quality one, so I don't want to post them on the web server where I normally post links here. If anyone has a web server they would like to host the current files on, I'd be happy to send them links to the files.

Bryan Waters · 2012-12-18, 21:11

Hi there i can host them aswell if need be

**Travis Cobbs** · 2012-12-18, 23:42

Send an email to LDView's email address, and I'll send you a link to the files.

**Michael Heidemann** · 2012-12-19, 16:02

I think you do not need to add a separate column for the keywords.
The picture is big enough that you can have two or three lines of text. IMHO

If I would search in that pdf for a special part, I just search for text.

**Travis Cobbs** · 2012-12-19, 17:50

I had in fact considered something like that, but it creates difficulty, because there's no obvious column to put the keywords into. Another alternative is to just make the text be multi-line, with prefixes, but that might greatly increase the page count, because there are a whole bunch of quite small parts that currently only take up the space of one to two lines of text. So, if I add keywords, the layout might look like the following:

Code:
_=_

Description: Minifig Head with SW Scout Trooper                    /0"0\

       File: 3626bpse.dat                                          | ' |

   Keywords: Star Wars, Episode VI, Empire, Speeder Bike, Endor    \___/

Note: I used the code tag above to line things up. The actual HTML I output would use HTML for the alignment.

The advantage of the above is that it would remove the need for the column headers at the top of each page. And, perhaps it would be easier to read.

Thoughts?

**Steffen** · 2012-12-19, 17:52

I like this multiline approach, it facilitates searching within the file and looks just nice and right to me.
But I would put the image in the left column.

**Travis Cobbs** · 2012-12-19, 18:18

The reason the image is on the right is because Willy (justifiably) complained about right-justified images when the image was on the left. And, since the images vary so greatly in size, they really need to be right-justified when on the left. Overall, I think having them left-justified on the right works better than right-justified on the left. Having them left-justified on the left just looks bad.

I will generate a file with the above modified formatting without keywords to see what it looks like. If it looks good, I'll add the necessary code to my script to include keywords when present (skipping that line for files with no keywords).

**Steffen** · 2012-12-19, 18:45

hmm, what about "horizontally centered within the leftmost column"? does that look better?

**Travis Cobbs** · 2012-12-19, 19:41

The images range in size from about 20 pixels wide all the way up to 512 pixels wide. If they are centered, the that decreases the size of the maximum possible space from 492 pixels down to 246 pixels (plus inter-column spacing), but it's still a very big gap. On the flip side, the new text will have a wide range of widths also, while my current middle column is the filename, which has a fairly narrow range of widths. So I may have to put the images on the left again (probably right-justified in their column).

**Travis Cobbs** · 2012-12-21, 18:41

Well, I modified my script to change the format to something similar to my above ASCII art (but with the image on the left of the text), but unfortunately, the updated table completely failed to import into Libre/OpenOffice with proper formatting. The only way I could find to nicely provide the above format was to use an embedded three row/two column table for each part's text data, and apparently that's not supported well by Libre/OpenOffice.

Word 2008 for Mac did a much better job importing the HTML, but had a different set of problems, so I'm going to investigate to see if I can fix those problems, and also investigate to see if I can come up with formatting that Libre/OpenOffice can handle, and still looks good.

**Travis Cobbs** · 2012-12-21, 18:55

After posting this, I realized that I had been stupid not to try rowspan=3 on the image column and using 3 separate rows in the main table to get the three rows of text, so I'll see if Libre/OpenOffice do a better job handling rowspan than they do handling tables embedded inside other table cells.

**Michael Heidemann** · 2012-12-21, 19:20

That should work. I have tried it this way.

**Steffen** · 2012-12-22, 20:55

as we have some fairly HUGE parts, it could maybe be an idea do restart a new table every, say, 100 parts, or when the first word of the title changes.
this way these large part exceptions won't force the whole table to have an unnecessarily wide picture column.
another idea could be to, if an image exceeds a certain pixel size, exceptionally scale it with a different factor.

(sorry, if you already have incorporated ideas like these, I had no time to check that)

Login
Username:
Password:	Lost Password?
	Remember me